Live data from Hacker News

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

news.ycombinator.com

41–50 of 300 posts

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

#41
post #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".

WASM doesn't have jumps [1]. And it's not as low-level as you might expect. But even still you're assuming that low level means a specific model of computation a la PDP-11 that's as fictional as any other.

https://webassembly.github.io/spec/core/syntax/instructions....

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

#42
post #40
post #6

Earlier quoted context omitted.

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.

Firefox can’t eliminate tail call across realms. The spec could make an exception for that scenario

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

#44

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?

I don't like liver and horse radish either. Should I eat that because a lot of people like it?

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

#45

Earlier quoted context omitted.

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 ret…

Interesting. I'll learn more today as I rewrite one of my Dart components into TypeScript. But I also dislike Node and Npm so I'll try Deno first.

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

#46
post #41
post #37

Earlier quoted context omitted.

> 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".

WASM doesn't have jumps [1]. And it's not as low-level as you might expect. But even still you're assuming that low level means a specific model of computation a la PDP-11 that's as fictional as any other. https://webassembly.github.io/spec/core/syntax/instructions....

I never expected WASM to be low-level to begin with, so I don't believe it could ever possibly be "as low level as I might expect". Something like NaCl (the original one) perhaps could have been called "low level".

> But even still you're assuming that low level means a specific model of computation a la PDP-11 that's as fictional as any other.

I don't see how jumps are "fictional". Plenty of CPUs have them. Even actual stack CPUs, for that matter.

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

#47
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 think its Rich Hickey who said something to the effect that tail calls are so fundamental that the underlying platform should be providing them.

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

#48
post #22

Earlier quoted context omitted.

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 otherwi…

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.

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

#50
Tail calls are super important for non-C like control flow, and it's great that it might be added.

But what I really think wasm should focus on is to get near native performance (say, <50% overhead). Until that happens, the whole endeavor seems pointless to me.

Post reply on HN