Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 300 posts

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

#81

Post by shadowgovt »

jhgb wrote: post #70
shadowgovt wrote: post #69

Earlier quoted context omitted.

To be clear, I deleted that comment because it was inaccurate. GLSL has break, continue, and return, which are flow-control statements. It excludes goto, and my explanation for why it excludes goto is probably incorrect (but I don't have time today to rabbit-hole on why goto was excluded or why the SIMD architecture can support break and continue just fine while excluding goto). > In case of sequential machines, I do…

Maybe it was inaccurate but I got what you were trying to say -- that "incoherent execution" is difficult on SIMD machines. > You may be interested to consider how incredibly complex the modern x86 architecture is to implement because it supports sequential program execution as a core invariant principle. As a result, modern computers (which strive to be faster than a PDP-11) have to do a massive amount of work to pa…

You might be interested in a fascinating game called TIS-100 by Zachtronics. The game is a lot of things, but a core premise is that it imagines a computer from a time approximately parallel to the PDP-11 that took the form of small compute components that were connected to each other instead of a monolithic central processor. It's a fun game, and it sort of raises the question of which is the "abomination[s] forced on us as an accident of history." Because when you look around at most of the biological world, you see heavily distributed systems with some centralization, but computers (man-made things that they are) are heavily centralized, clock-locked, deterministic... And energy-intensive. And slow.

History is arbitrary but not random, and it's fun to think about how things might have been different if the first machines started embarrassingly parallel with follow-up work to consolidate the data instead of embarrassingly centralized with us now in the era of how to make the monoliths fast. It's interesting to think about what's "ideal" about a machine that supports arbitrary jumps (and the global address space that demands, and the sequential execution necessary to prevent decoherence, and the memory protection demanded because some addresses are not executable code and should never be executed, etc., etc.).

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

#82

Post by labrador »

FlorianRappl wrote: post #78
labrador wrote: post #15

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

The comment reads like you used JavaScript 10 years ago. For instance, just use arrow functions and this remains untouched.

I know but that's just bizarre. One function has it's own this and another doesn't so if my arrow function gets big and I want to make it a regular function I may have to rewrite it. Ugh.

Edit: I'm thinking of cognitive load too. I like to eliminate load I don't need. Keeping track of this is not something I want to do with my life

https://drpicox.medium.com/reducing-programmers-cognitive-ov...

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

#83

Post by atwood22 »

wruza wrote: post #75
shadowgovt wrote: post #55

Earlier quoted context omitted.

TBH, TypeScript's type system really impressed me. It's the strongest type system of any language I regularly use (I haven't had time to unpack Rust yet, and I learned enough Haskell to decide Haskell didn't help me solve problems I had).

It’s an expressive type system, but ime it allows developers to go crazy on type interdependencies and general entanglement, so you can’t just go to the “header” and quickly figure out what your method or a return value really is, despite TS has structural typing. E.g. look at this: https://github.com/telegraf/telegraf/blob/v4/src/telegram-ty...

That's definitely overwhelming. After reading it for 5 minutes though, there is a type called Telegram and it has a field called 'Opts' that has a lot of different fields. MakeExtra lets you take a type from 'Opts' and exclude certain parameters. Probably do something like "you can set the chat message contents, but you can't set the chat id"

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

#84

Post by vbezhenar »

RHSeeger wrote: post #11
codedokode wrote: post #8

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.

Those algorithms usually use non-tail recursion. Most tail recursion uses usually is trivial to rewrite in a loops.

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

#85

Post by jhgb »

shadowgovt wrote: post #81
jhgb wrote: post #70

Earlier quoted context omitted.

Maybe it was inaccurate but I got what you were trying to say -- that "incoherent execution" is difficult on SIMD machines. > You may be interested to consider how incredibly complex the modern x86 architecture is to implement because it supports sequential program execution as a core invariant principle. As a result, modern computers (which strive to be faster than a PDP-11) have to do a massive amount of work to pa…

You might be interested in a fascinating game called TIS-100 by Zachtronics. The game is a lot of things, but a core premise is that it imagines a computer from a time approximately parallel to the PDP-11 that took the form of small compute components that were connected to each other instead of a monolithic central processor. It's a fun game, and it sort of raises the question of which is the "abomination[s] forced…

> and it sort of raises the question of which is the "abomination[s] forced on us as an accident of history."

What I meant by that is the legacy of AMD64 having thousands of instructions, many of them with arbitrary opcode encoding, half-assed SIMD ISA instead of a proper vector ISA, and the ability to emulate an 8086, all purely for reasons of backwards compatibility. If you started designing a computing ecosystem completely from scratch, surely you wouldn't end up with an AMD64-based IBM PC descendant as your best idea you could come up with?

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

#86

Post by nu11ptr »

apignotti wrote: post #18
j-pb wrote: 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…

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

Possibly a stupid question as I haven't given this much thought, but I thought tail call elimination could be used to convert recursive calls in tail position into loops. Could a compiler not do this (like Scala does, for example)?

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

#87

Post by samatman »

nu11ptr wrote: post #86
apignotti wrote: post #18

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 Possibly a stupid question as I haven't given this much thought, but I thought tail call elimination could be used to convert recursive calls in tail position into loops. Could a compiler not do this (like Scala does, for example)?

Tail-call elimination applies to any function which calls another function as the last action.

Turning this into a loop is only possible when the function calls itself, not when it calls another function, and not (naively) when two functions call each other in the tail position.

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

#88

Post by chmod775 »

labrador wrote: post #82
FlorianRappl wrote: post #78

Earlier quoted context omitted.

The comment reads like you used JavaScript 10 years ago. For instance, just use arrow functions and this remains untouched.

I know but that's just bizarre. One function has it's own this and another doesn't so if my arrow function gets big and I want to make it a regular function I may have to rewrite it. Ugh. Edit: I'm thinking of cognitive load too. I like to eliminate load I don't need. Keeping track of this is not something I want to do with my life https://drpicox.medium.com/reducing-programmers-cognitive-ov...

> so if my arrow function gets big and I want to make it a regular function I may have to rewrite it.

There's absolutely no reason to make an arrow function a regular function just because it goes past a certain number of lines.

It really seems like you should become more familiar before forming an opinion. There's valid criticism to be made, but those aren't it.

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

#89

Post by nu11ptr »

samatman wrote: post #87
nu11ptr wrote: post #86

Earlier quoted context omitted.

> Tail-calls is fundamentally something that the compiler _cannot_ solve Possibly a stupid question as I haven't given this much thought, but I thought tail call elimination could be used to convert recursive calls in tail position into loops. Could a compiler not do this (like Scala does, for example)?

Tail-call elimination applies to any function which calls another function as the last action. Turning this into a loop is only possible when the function calls itself, not when it calls another function, and not (naively) when two functions call each other in the tail position.

Understood, but in practice how often does that really happen? (I'm aware of the contrived 'odd'/'even' example always given, but in the real world, I never had anything like that). Even when I wrote more functional code I rarely (if ever?) did that. 98-99% of the time it was the same function calling itself. Is your experience different?

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

#90

Post by convolvatron »

apignotti wrote: post #5
convolvatron wrote: post #2

I'm working on a relational stream processor and this is pretty critical to making it work well. a runtime standard with support for network connections would be nice too, but lets not get greedy

> support for network connections I wish daily for that as well, but stay tuned: we _might_ have found a half-satisfactory solution for that ;-)

pointer to a draft?
Post reply on HN