4 ms·
I would say that schemes looping constructs are too limited for comfortable use, but that tail call elimination makes implementing your own constructs very easy
by bjoli 8y ago
I would say that schemes looping constructs are too limited for comfortable use, but that tail call elimination makes implementing your own constructs very easy. I have reimplemented racket's for loops for guile using named let loops [0] which was not only pretty easy, but it was also easily understood and optimised by the guile compiler. The end result is as fast as a hand rolled named let for almost all cases (I still haven't found one where it is measurably slower, but I have only tested it in the repl where the compiler can make lots of assumptions)
For that reason alone I think tail call elimination is a must, especially in today's transpiling world.
[0]: https://bitbucket.org/bjoli/guile-for-loops https://bitbucket.org/bjoli/guile-for-loops
- soegaard 8y ago"For that reason alone I think tail call elimination is a must, especially in today's transpiling world." This is an important insight. I feel the JavaScript implementors are dragging their on getting tail call elimination widely supported.
- bjoli 8y agoI have re-implemented rackets for loops using named let in a way that allows me to almost reach feature parity in a weekend [0]. I could implement python's list comprehensions the same way without much fuss. I can't imagine having to do the same using an already existing looping construct with it's own edge cases and subtle semantics. [0]: I didn't think about post-guards when I started, and adding them now would mean having to do some restructuring of the quite hairy emitting macro, which I won't do since I don't see the use case for post guards for anything else than making in-value a bit more elegant
- kccqzy 8y agoES6 used to mandate TCE but it was removed. No browser other than Safari implements TCE for JavaScript. Apparently the main reason is an inaccurate stack trace on exception.
- bjoli 8y agoI can understand that, but it is a shame they didn't chose to do so for self-recursing functions. That would at least tell you the stack trace up until that point.
- soegaard 8y agoAn often over-looked point: If you use tail calls to implement a loop, you aren't really interested in seeing the stack trace. Compare with a standard for-loop: you aren't interested in seeing all states of the for-loop in a stack trace.
- hajile 8y agoThe latest spec still talks about tail call optimization. The big objection was to replace implicit tail calls with a syntax to specify functions that might tail call. With TCO being part of the spec and the potential replacement spec killed off, browsers really need to start getting with the program. JavascriptCore (safari), Node v6, duktape, jerryscript, XS6, etc all have proper tail calls. It breaks the community to not implement them. It's not a standard if its not standard.
- soegaard 8y agoExplicit or implicit doesn't matter for compiling to JavaScript. Explicit tail calls are much better that no tail call support at all.
- hajile 8y agoI agree, but the companies behind explicit calls dropped it, but are refusing to implement the current spec too. Their stupid politics endanger the js ecosystem.