It doesn't and I hope whoever is in charge of web assembly doesn't ruin what they have by giving in to nonsense trends that are part of a silver bullet syndrome and don't offer real utility.
For example, it's done by all of the Schemes, all of the MLs (SML, Ocaml, Haskell, Rust, Scala, Idris, etc.), scripting languages (Lua, Elm, Perl, Tcl, etc.), and many others.
> that are part of a silver bullet syndrome and don't offer real utility
Their "real utility" is right there in the subtitle of that original paper:
Debunking the "Expensive Procedure Call" Myth
or, Procedure Call Implementations Considered Harmful
or, Lambda: The Ultimate GOTO
In other words, any implementation of procedure/function/method-calls which doesn't eliminate tail-calls is defective (slow, memory-hungry, stack-unsafe, etc.)
Not standard, since almost no programming is actually done using tail calls. Programming is done with loops, tail calls are an exotic and niche way of working.
Even in lua and rust tail calls are rarely used and the other languages you listed are extremely niche.
Debunking the "Expensive Procedure Call" Myth
or, Procedure Call Implementations Considered Harmful
or, Lambda: The Ultimate GOTO
These are not explanations of utility, these are titles that you are using to claim something without backing it up.
In other words, any implementation of procedure/function/method-calls which doesn't eliminate tail-calls is defective (slow, memory-hungry, stack-unsafe, etc.)
This is a very bold claim with no evidence for it and pretty much the entire history of programming against it.
Also, it was literally the title of a paper. If citing the literature with a hyperlink to wikisource doesn't count as "backing it up", then I have no idea where you put the goalposts.
> almost no programming is actually done using tail calls
Literally every function/procedure/method/subroutine/etc. has at least one tail position (branching allows more than one). It's pretty bold to claim that there are 'almost no' function calls in those positions. I wouldn't believe this claim without seeing some sort of statistics.
> Programming is done with loops, tail calls are an exotic and niche way of working.
Loops have limited expressiveness; e.g. they don't compose, they break encapsulation, etc. Hence most (all?) programs utilise some form of function/method/procedure/subroutine/GOTO. Tail-calls are simply a sub-set of the latter which, it turns out, are more powerful and expressive than loops (as an obvious example: machine-code doesn't have loops, since it's enough to have GOTO (AKA tail-calls)).
That wasn't 'me claiming something', it was Guy L Steele Jr.
You still just copy and pasted titles, this isn't evidence of anything.
If citing the literature
Then put in the part you think is evidence or significant. This is the classic "prove my point for me" routine. You're the one who wants to change a standard.
Literally every function/procedure/method/subroutine/etc. has at least one tail position
Are you conflating general functions with tail call elimination?
Loops have limited expressiveness; e.g. they don't compose, they break encapsulation,
Why would that be true? How would looping through recursion change this?
Hence most (all?) programs utilise some form of function/method/procedure/subroutine/GOTO
What does this have to do with tail call optimizations? Web assembly has functions.
machine-code doesn't have loops,
Web assembly is not the same as machine code
I think overall you are thinking that making claims is the same as evidence. You haven't explained any core idea why tail call optimizations have any benefit in programming or web assembly. You basically just said a well known language creator put them in some languages. There is no explanation of what problem is being solved.
Indeed; if web assembly allowed unrestrained GOTOs (like machine code) then compilers would already be able to do tail-call elimination.
---
> Are you conflating general functions with tail call elimination?
> What does this have to do with tail call optimizations?
> You haven't explained any core idea why tail call optimizations have any benefit
Sorry, I think there have been some crossed wires: I was mostly pointing out the absurdity of your statement that "almost no programming is actually done using tail calls" (when in fact, almost all programs will contain many tail-calls).
That's separate to the question of how tail-calls should be implemented: in particular, whether they should perform a GOTO (AKA tail-call elimination/optimisation); or, alternatively, whether they should allocate a stack frame, store a return address, then perform a GOTO, then later perform another GOTO to jump back, then deallocate that stack frame, etc.
> You haven't explained any core idea why tail call optimizations have any benefit in programming or web assembly
Based on my previous sentence, I would turn the question around: what benefit is gained from allocating unnecessary stack frames (which waste memory and cause stack overflows), performing redundant jumps (slowing down programs), etc.?
almost no programming is actually done using tail calls
I'm talking about tail call optimization, which is what this whole thread was about, what you are you talking about?
Based on my previous sentence, I would turn the question around:
That's not how it works, since you're the one wanting a standard to change.
what benefit is gained from allocating unnecessary stack frames
Where are you getting the idea the webasm JIT has to allocated 'unnecessary stack frames'.
stack frames (which waste memory and cause stack overflows)
This makes me think you don't understand how the stack even works. The memory is already there and stack memory is very small. You can't both 'waste memory' and overflow the stack at the same time. This stuff is fundamental to how computers work.
It seems like you don't even know or understand what problem you are trying to solve. Where did you get this absurd idea that the stack is a problem? Also do you think that rust doesn't use a stack?
