Live data from Hacker News

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

news.ycombinator.com

281–290 of 300 posts

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

#281

Earlier quoted context omitted.

Maybe I'm naive and I surely don't know anything about the WASM spec, but aren't CPUs implementing both exceptions and tail call elimination as gotos (some jump machine code instruction) ? Exceptions might have to pop some frame, TCE doesn't.

To avoid some classes of security issue, and also because it started much closer to asm.js in features, WASM uses structured programming control flow like blocks, if..then, and break statements. Functions can only be called by the call instruction right now, so this proposal is needed to jump to an function body.

Are you saying there is no goto in wasm ? Genuine question I don't have any knoweldge of WASM.

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

#282

Earlier quoted context omitted.

If it is a mistake depends on the point of view. What seems to be more important: exceptions of tail-call elimination? Most modern languages use exceptions in one way or another, conversely very few use the later feature. From the point of view of existing software it is way more important to optimize VMs for exception handling than for tail call elimination.

Well wasm doesn't have exceptions right now either! The exceptions proposal is also in phase 3, like tail-calls. Right now wasm just supports traps, which can't be caught or inspected from within wasm code, and don't actually need to record stack frames (but the JavaScript host does in web browsers). I'm not sure what benefit exposing the wasm part of the stack for traps gives the JavaScript host side except perhaps…

Well WTF is this doing https://docs.rs/wasm-bindgen/0.2.11/wasm_bindgen/fn.throw.ht... then ?

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

#283

Earlier quoted context omitted.

Well wasm doesn't have exceptions right now either! The exceptions proposal is also in phase 3, like tail-calls. Right now wasm just supports traps, which can't be caught or inspected from within wasm code, and don't actually need to record stack frames (but the JavaScript host does in web browsers). I'm not sure what benefit exposing the wasm part of the stack for traps gives the JavaScript host side except perhaps…

Well WTF is this doing https://docs.rs/wasm-bindgen/0.2.11/wasm_bindgen/fn.throw.ht... then ?

Calling into an external JavaScript function, which will then throw a JavaScript exception (as the linked documentation states).

Wasm cannot throw the exception itself, nor can it catch the exception. How exceptions are handled when raised in code called via FFI in another language are a property of the embedding and wasm engine, not of wasm itself, which (as of yet, barring that exceptions proposal) has no concept of them besides unrecoverable traps.

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

#284
post #7

I'm using Blazor (C#) WebAssembly and I'm really wishing it could do DOM manipulation. My favorite tool for that is Dart, so I'm working on marrying C# and Dart for my client solutions.

I was struck by how reactionary some of the responses to this comment are. Many people seemed to feel obliged to firmly question your preferences. Kind of odd, I don't normally notice that as much here on HN.

I expected it because over the years any Dart or Microsoft positive statements I've made have received pushback. Some people can't let go what Microsoft did 20 years ago and assume they are still evil (with GitHub Copilot for example.) Others who are JavaScript programmers can't let go that a Google exec said at the outset that Dart was meant to replace JavaScript. They have fought it over the years.

I almost felt like I was trolling by combining the two, but I'm actually using Dart and Blazor to see how they can work together because Blazor Wasm doesn't do DOM manipulation and Dart does it in such a easy to use fashion that the marriage feels natural to me.

I try not to attack back and have a bit of a sense of humor about it, but it does feel like suppression of thought on HN

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

#285

Earlier quoted context omitted.

Well WTF is this doing https://docs.rs/wasm-bindgen/0.2.11/wasm_bindgen/fn.throw.ht... then ?

Calling into an external JavaScript function, which will then throw a JavaScript exception (as the linked documentation states). Wasm cannot throw the exception itself, nor can it catch the exception. How exceptions are handled when raised in code called via FFI in another language are a property of the embedding and wasm engine, not of wasm itself, which (as of yet, barring that exceptions proposal) has no concept o…

Great thank you for the info

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

#286

Earlier quoted context omitted.

To avoid some classes of security issue, and also because it started much closer to asm.js in features, WASM uses structured programming control flow like blocks, if..then, and break statements. Functions can only be called by the call instruction right now, so this proposal is needed to jump to an function body.

Are you saying there is no goto in wasm ? Genuine question I don't have any knoweldge of WASM.

Yes, that is correct.

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

#287

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…

> 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?

A trampoline is a workaround that wastes memory and time. The idea is to avoid that so that you can use function calls efficiently.

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

#288
post #179
post #7

I'm using Blazor (C#) WebAssembly and I'm really wishing it could do DOM manipulation. My favorite tool for that is Dart, so I'm working on marrying C# and Dart for my client solutions.

What's C# giving you that Dart isn't, OOI? My impression is they're fairly similar languages. (Does Dart not have a WebAssembly backend?)

Blazor is using C# to build web pages, which isn't new, but using C# on the client with a webassembly version of .NET. It works well enough, but is limited to simple things like onClick="SomeCSharpFunction" and can not do things like getting elements by id or class. That's were Dart shines. Most will use either JavaScript or TypeScript, but I like Dart so I want to see how it is to combine Blazor Webassembly with Dart.

It would be even more interesting if there were a Dart.NET

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

#289
post #265

Earlier quoted context omitted.

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.

Has there been any movement on that (or funclets) recently? All the repos I can find haven't been updated in a while.
Post reply on HN