That sounds super nice! Maybe this will turn out to be a nice way of compiling languages which make heavy use of tail calls to the browser (I'm thinking Haskell, Purescript, Erlang, Ocaml).
For purescript specifically this means no MonadRec needed which is quite exciting! (if and when a wasm backend is made, ofc)
Tell HN: We are trying to get tail calls into the WebAssembly standard
261–270 of 300 posts
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#262Earlier quoted context omitted.
This might be a silly question, but why is that a nightmare scenario? The exact same argument could be made for any compile-time optimization. If one compiler inlines a function where another doesn't, or unrolls a loop, or performs better constant propagation, any of those could impact the resource usage between the two compilers, leading to exactly that same scenario. But I wouldn't want to forbid improvements altog…
> The exact same argument could be made for any compile-time optimization. No. For other optimization, the difference is the speed of execution. For tail call optimization, the difference can be normal execution and stack overflow.
Any optimization that removes an unnecessary stack allocation could also be the difference between normal execution and stack overflow, due to decreasing the size of the stack frame.
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#263Sorry 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…
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…
> 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.
I have been out of the loop regarding compilers development for a long time but what prevents you from converting your program to CPS and using a trampoline like some LISP still do?
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#264Earlier quoted context omitted.
I think its Rich Hickey who said something to the effect that tail calls are so fundamental that the underlying platform should be providing them.
And yet Clojure doesn’t have general tail calls (it has recur which allows something like tail calls so long as they are non-mutually recursive) and seems to do ok.
Yes its in the context of Clojure, his point is tail calls should be provided in JVM itself, it can then be added to Clojure.
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#265Earlier quoted context omitted.
I'm all for rewriting things from scratch. That's why I'm doing a new Wasm engine from scratch. But reusing TurboFan is how we took Wasm from concept to near-native performance, shipped in Chrome, in 2.5 years.
That's all well and good - but, again, the spec will be around for decades . Compromises made today to ship things faster means a lot of pain in those years ahead. I pity all the compiler writers who will have to implement relooper again and again. But instead we'll probably do things like asm.js - that is, bless certain wasm patterns such that advanced VMs would be guaranteed to optimize them. And so everything will…
That's why multiloop is coming.
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#266Earlier quoted context omitted.
I once wrote an interpreter in continuation-passing style, meaning every final line of a function called the next function in the interpreter, passing a continuation and error continuation on. Such a program never returns until it finishes interpreting, and can make an unlimited number of such calls. This is a bad idea without TCE.
Why couldn't the compiler inline the whole interpreter?
Because in the continuation-passing style, the functions-calling-functions are circular in many places, inlining would explode rather than halting.
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#267Earlier quoted context omitted.
> Reference types maybe. But I've yet to see a convincing argument as to why they are absolutely necessary. Are you referring to WASM GC here (or managed memory in general)? If so, I think the main compelling reason is interop. Without GC in underlying architecture, any managed language targeting WASM must include its own runtime and GC. If you then want to write a polyglot program using multiple languages, you now h…
I'm likely in the minority in my thinking, but I don't think targeting wasm with managed languages is such a great use case for wasm anyway, and so it wasn't worth building in GC to support. For the times you want to, something light like reference counting should be easy enough.
If your language uses a tracing GC, you can’t just add reference counting and expect existing programs to work without memory leaks
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#268Neat! This proposal caused me a lot of headaches, mechanizing its specification was the primary contribution of my Master's thesis a couple years ago[1]. I forgot until rereading it just now, but doing so caught a typo in the proposal specification[2], my extremely minor contribution to advancing WebAssembly. Glad to see it finally moving forward after stalling for so long! Excellent work! [1]: https://github.com/jac…
That might be the shortest (in word count) Master's thesis I have ever seen!
Looks typical for a master's thesis to me. Maybe you're thinking of a PhD thesis?
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#269Would this mean that relooper etc. are no longer needed since you can just have all your basic blocks as functions and use tail calls to jump between them?
Re: Tell HN: We are trying to get tail calls into the WebAssembly standard
#270Earlier quoted context omitted.
I think its Rich Hickey who said something to the effect that tail calls are so fundamental that the underlying platform should be providing them.
And yet Clojure doesn’t have general tail calls (it has recur which allows something like tail calls so long as they are non-mutually recursive) and seems to do ok.
[deleted]