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

291–300 of 300 posts

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

#291

Post by anitil »

diarrhea wrote: post #244
jacobmischka wrote: post #24

Neat! 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!

Claude Shannon's masters thesis was quite short as well [0], around 25 pages!

[0] https://www.cs.virginia.edu/~evans/greatworks/shannon38.pdf

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

#292

Post by diarrhea »

IshKebab wrote: post #268
diarrhea wrote: post #244

Earlier quoted context omitted.

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?

No, in my industry (mechanical engineering) Master (and also Bachelor) theses were always much, much longer. Longer lines, less vertical line spacing, many more pages. Lots of faffing about ('Introduction', 'State of the Art', 'Theoretical foundation', ...). Faculties urge supervisors and students to keep it below 100 pages (of relatively dense type).

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

#293

Post by lmm »

labrador wrote: post #288
lmm wrote: post #179

Earlier quoted context omitted.

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

My point is: why C#, why Blazor? What's that doing that you couldn't just do in Dart itself?

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

#294

Post by traviswt »

kbelder wrote: post #189
labrador wrote: 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.

Well personally I wasn't questioning the preference itself, I was curious about the purpose of the preference since I've seen people avoid JS/TS both because they don't like it and because it struggles to accomplish certain things. I was simply curious which it was (if either).

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

#295

Post by jacobmischka »

diarrhea wrote: post #292
IshKebab wrote: post #268

Earlier quoted context omitted.

Looks typical for a master's thesis to me. Maybe you're thinking of a PhD thesis?

No, in my industry (mechanical engineering) Master (and also Bachelor) theses were always much, much longer. Longer lines, less vertical line spacing, many more pages. Lots of faffing about ('Introduction', 'State of the Art', 'Theoretical foundation', ...). Faculties urge supervisors and students to keep it below 100 pages (of relatively dense type).

Agreed on the formatting of mine being ridiculous with huge margins and line spacing, it wasn't my choice.

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

#296

Post by kragen »

yw3410 wrote: post #202
kragen wrote: post #152

Earlier quoted context omitted.

How does that work on the JVM?

Scala only does single method tail recursion and rewrites it into a while loop. Cats and other libraries use a technique called trampolining which basically moves the frames to the heap (or a mixed technique where they do recurse a certain depth on the stack before switching to trampolining).

That sounds like it means that Scala doesn't support general tail-call elimination, so people don't write mutually tail-recursive code, instead transforming things that would naturally be expressed that way into a different structure that Scala does support.

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

#297

Post by MereInterest »

quietbritishjim wrote: post #278
MereInterest wrote: post #213

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

That is exactly why tail call "optimisation" is not, in fact, an optimisation. Indeed much of this discussion, including the title and text of the original post, carefully avoids using the word "optimisation". Somehow it got introduced at some point in these comments. To flip it the other way: consider a normal (non-tail-call) program and choose a local variable in a routine that happens to be called quite a lot. Rep…

> Replace it with a list that you append to every time you call the routine, even though only the last entry is ever examined. The program will leak memory, potentially quite quickly, and eventually crash.

I had to think on this example a bit, but I believe these programs exist and are quite common. This is an accurate description of any program in which memory is allocated and never explicitly freed. Some languages include runtimes that perform garbage collection, but until the garbage collection runs, the program is leaking memory and would crash without the garbage collection.

Which is to say, I think I agree with you, but had to chew over the example a bit. That it isn't a quantitative difference in speed or memory usage, but a qualitative difference in the types of programs that are acceptable in a language. Thank you for it.

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

#298

Post by haberman »

quietbritishjim wrote: post #278
MereInterest wrote: post #213

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

That is exactly why tail call "optimisation" is not, in fact, an optimisation. Indeed much of this discussion, including the title and text of the original post, carefully avoids using the word "optimisation". Somehow it got introduced at some point in these comments. To flip it the other way: consider a normal (non-tail-call) program and choose a local variable in a routine that happens to be called quite a lot. Rep…

> Is it fair to say it's just less optimised than before? I would say it's worse than that: it has an actual bug.

Yes, a program that depends on tail call optimization, despite having no guarantee of tail call optimization being performed, has a bug.

That doesn't mean that tail call optimization is not an optimization. In languages that allow, but do not guarantee, tail call elimination, it is an optimization performed by the optimizer that makes a program run more optimally than it would have otherwise. There is a long history of referring to it as an optimization, for example in the docs of LLVM: https://llvm.org/docs/LangRef.html#call-instruction

I don't think it makes sense to redefine the word "optimization" such that it excludes examples where a program could erroneously depend on a certain optimization being performed.

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

#299

Post by quietbritishjim »

haberman wrote: post #298
quietbritishjim wrote: post #278

Earlier quoted context omitted.

That is exactly why tail call "optimisation" is not, in fact, an optimisation. Indeed much of this discussion, including the title and text of the original post, carefully avoids using the word "optimisation". Somehow it got introduced at some point in these comments. To flip it the other way: consider a normal (non-tail-call) program and choose a local variable in a routine that happens to be called quite a lot. Rep…

> Is it fair to say it's just less optimised than before? I would say it's worse than that: it has an actual bug. Yes, a program that depends on tail call optimization, despite having no guarantee of tail call optimization being performed, has a bug. That doesn't mean that tail call optimization is not an optimization. In languages that allow, but do not guarantee, tail call elimination, it is an optimization perform…

OK, if you prefer to be precise, there are two situations:

(1) In languages (or runtimes) where tail calls are not guaranteed to be elided, tail call elision is an optimisation. In that context, you could quite reasonably describe it as tail call optimisation. Programs that are written in these languages and rely on tail call elision are buggy.

(2) In languages (or runtimes) where tail calls are guaranteed to be elided, tail call elision is not an optimisation. In that context, you cannot reasonably describe it as tail call optimisation. Programs that are written in these languages and rely on tail call elision are not buggy (at least, not for that reason!).

This conversation is about making tail call elision a guaranteed feature of WASM. Therefore, in this context, it is not reasonable to describe tail call elision as an optimisation.

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

#300

Post by yw3410 »

kragen wrote: post #296
yw3410 wrote: post #202

Earlier quoted context omitted.

Scala only does single method tail recursion and rewrites it into a while loop. Cats and other libraries use a technique called trampolining which basically moves the frames to the heap (or a mixed technique where they do recurse a certain depth on the stack before switching to trampolining).

That sounds like it means that Scala doesn't support general tail-call elimination, so people don't write mutually tail-recursive code, instead transforming things that would naturally be expressed that way into a different structure that Scala does support.

Yes. It can be a major PITA, in certain problem spaces and I think most people don't pretend it's a great solution but ultimately accept it as a limitation of being hosted on the JVM.
Post reply on HN