Live data from Hacker News

Tell HN: We are trying to get tail calls into the WebAssembly standard

news.ycombinator.com

31–40 of 300 posts

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#31

Recursion indeed can be useful when working with trees or graphs. However, I don't like using recursion instead of a loop, because you make reader to unroll your code in their head to understand what it really does. If you need to add two arrays of numbers, use loop or array addition, but don't use recursion as a replacement for a loop. Sadly the article uses a poor example, writing a useless factorial function. I ha…

> If you need to add two arrays of numbers, use loop or array addition There are plenty of algorithms that make more sense when expressed using recursion. Iterating over a list of numbers generally isn't one of them. But walking a tree is a good example.

More specifically: if you don't want to recursively iterate a tree, you have to hold a list of prior nodes to return to anyway... which is no different from weaving that information into the stack. Non-recursive iteration in this case literally requires you to emulate the recursion.

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#32

Earlier quoted context omitted.

I really dislike JavaScript for a number of reasons. Dart gives me more distance from it than TypeScript. Of course, I can't avoid it, but I don't have to deal with many annoyances such as which 'this' is this? Should I put 'this' into a var called 'self' to be safe? That's just one example of how JavaScript and I don't get along. I understand some people have brains that think this way, but mine doesn't

> I really dislike JavaScript for a number of reasons. Might I suggest being less sensitive/that your reasons are overblown?

Yes, let's keep using JavaScript for all eternity now. It's COBOL of this century.

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#33

Earlier quoted context omitted.

I really dislike JavaScript for a number of reasons. Dart gives me more distance from it than TypeScript. Of course, I can't avoid it, but I don't have to deal with many annoyances such as which 'this' is this? Should I put 'this' into a var called 'self' to be safe? That's just one example of how JavaScript and I don't get along. I understand some people have brains that think this way, but mine doesn't

Surely it's easier to stick to JavaScript The Good Parts than to introduce a whole new layer in the form of Blazor?

Blazor is not equal to JavaScript. Blazor is Microsoft's answer to React and Flutter. So far of the three, I like Blazor, but not the server version that uses SignalR to communicate with the client because it locks you in. Blazor Webassembly is awesome, but just needs a good DOM manipulation library. With Blazor Wasm on the client, I can use anything on the back end.

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#36

Earlier quoted context omitted.

What do you like about Dart over TypeScript? The type system in TypeScript is far superior to Dart's. Other than that, the languages are more-or-less the same.

Actually, I'm taking another look at TypeScript today. I liked it well enough when I last investigated it in 2016, but the code I wrote then was just a veneer over jQuery. I'm sure things have improved dramatically, which I am about to find out. Frankly, a Turing complete type system [1] seems like over-kill to me and a complication I don't need. Still, Dart had everything I wanted in a front end language in 2013. I…

I highly recommend TypeScript. I don't really like the JS runtime, but, purely from a language point of view, TS is my favorite.

Some cool features:

1) Type unions

interface A { a: string; }

interface B { b: string; }

type C = A | B;

const c: C = { a: 'a' };

2) Type assertions if ('a' in c) { /* compiler knows c is of type A here */ }

function isA(c: A): c is A { return 'a' in C } // compiler knows c is A if this returns true

3) Nice helper types interface A { ... }

ReadOnly // Like A, but all properties are read-only

Partial // Like A, but all properties are optional

Omit // Like A, but without 'someProp'

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#37
post #10

Sorry if I miss something obvious, but how is this not solvable by the compiler? I'm a huge functional programming evangelist, but high-level stuff like this does not belong in a low level language bytecode like WASM. Wasm should only care about two things: Security and Performance. With the standard blowing up like crazy we'll get neither. Worse, we'll cemenent the current duopoly of browser engines, because we'll m…

> I'm a huge functional programming evangelist, but high-level stuff like this does not belong in a low level language bytecode like WASM.

A tail call is a jump. Jumps are not "high-level stuff". They're very simple instructions. If WASM can't do a jump, it is actually WASM that you can't call "a low level bytecode".

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#38
Tangential but what's the status of garbage collection and DOM manipulation in WASM? Are we ever getting those? I understand it's a high-value technology without them, but I'm interested in writing full apps in say, OCaml (so I'm glad to hear that WASM is getting TCE!).

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#39
post #22

Earlier quoted context omitted.

Tail-calls is fundamentally something that the compiler _cannot_ solve. Trust me, if there was a way we would have avoided ourselves all this work. The issue is that to avoid stack blow-up you need the engine to recycle stack frames. You might argue that this could happen implicitly in the VM, with all the calls in tail position being automatically converted to tail-calls. The problem with this is that in WebAssembly…

Fair enough. Sounds more like an issue with .stack being an observable property though. I've long suspected exceptions making it into WASM being it's million dollar mistake, and this further confirms it.

I haven't messed with .stack, but on first impression I agree with you that it seems like a mistake.

Even if it wasn't observable though, I think guaranteed tail-call elimination via either a new opcode or having it be a required property of regular calls in the spec (we already missed that ship, of course) is important. Without it, proper compilation and execution of some languages on wasm would depend on an otherwise invisible property of the engine - that is, tail call elimination isn't just an optimization, it's a critical aspect of language semantics that needs to be guaranteed to be relied on.

Re: Tell HN: We are trying to get tail calls into the WebAssembly standard

#40
post #6

> tail-calls has been proposed as an extension to the WebAssembly standard. Do you know why it wasn't in the standard to begin with? Even ECMAScript 6 mandates PTC (proper tail call) - article from 2016 on Webkit.org no less - https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-...

The standard mandates it, and the V8 team implemented it, shipped it behind a flag, then unshipped based on reasons that initially seemed and ultimately were proven fuddy, when WebKit shipped PTC, and the world didn’t fall down. The reason actual why it was withdrawn is that it would have required expensive changes to Microsoft’s Chakra (the calling conventions were incompatible). Then Edge died... and Google didn’t…

If I understand what cross-realm means (code security), then I'm not sure that can be done at all.
Post reply on HN