Live data from Hacker News

Tail-call optimization added to 6to5 compiler

github.com

21–30 of 33 posts

Re: Tail-call optimization added to 6to5 compiler

#21
post #17

Earlier quoted context omitted.

In practice recursion probably covers most of the cases where it matters. Corecursion could (if awkwardly) be converted into ordinary recursion.

Corecursion doesn't mean what you think it means. You mean mutual recursion.

(read this with a mild trollface) Given functions f and g, it is possible to write them as the same function M. Supply an extra argument called "mode": if 0, then the function behaves like f, and if 1, then the function behaves like g. If you want to call f or g, call M with the "mode" argument as 0 or 1 respectively. If f and g take different numbers of arguments, let M take the larger number of arguments, and when you intend to call the function that takes fewer arguments, supply 0s for the extra args. This should indeed implement mutual recursion in terms of self-recursion.

The grandparent commenter did say "Corecursion could (if awkwardly) be converted into ordinary recursion", which I would say is technically correct, which some say is the best kind of correct. (Perhaps he has a somewhat less awkward scheme in mind.)

Re: Tail-call optimization added to 6to5 compiler

#22

Earlier quoted context omitted.

Corecursion doesn't mean what you think it means. You mean mutual recursion.

(read this with a mild trollface) Given functions f and g, it is possible to write them as the same function M. Supply an extra argument called "mode": if 0, then the function behaves like f, and if 1, then the function behaves like g. If you want to call f or g, call M with the "mode" argument as 0 or 1 respectively. If f and g take different numbers of arguments, let M take the larger number of arguments, and when…

You seem to be talking about mutual recursion.

http://en.wikipedia.org/wiki/Corecursion

http://en.wikipedia.org/wiki/Mutual_recursion

Re: Tail-call optimization added to 6to5 compiler

#23
post #3
post #2

I was literally complaining today about the fact that no-one seems to have yet implemented that part of the ES6 standard yet[1], and yet now here it is. As someone chiefly interested in .js for it's 'functional curious' side, the new features in ES6 have me really excited.

Which parts of es6 would you call 'functional curious'?

[deleted]

Re: Tail-call optimization added to 6to5 compiler

#24
post #3
post #2

I was literally complaining today about the fact that no-one seems to have yet implemented that part of the ES6 standard yet[1], and yet now here it is. As someone chiefly interested in .js for it's 'functional curious' side, the new features in ES6 have me really excited.

Which parts of es6 would you call 'functional curious'?

With destructuring and tco, the only thing its really missing is pattern matching on multiple function bodies.

Re: Tail-call optimization added to 6to5 compiler

#26
post #3

Earlier quoted context omitted.

Which parts of es6 would you call 'functional curious'?

With destructuring and tco, the only thing its really missing is pattern matching on multiple function bodies.

This would be the ultimate feature. Languages with dynamic dispatch would do well to implement this feature.

Re: Tail-call optimization added to 6to5 compiler

#27
post #16

Earlier quoted context omitted.

So, that sort of makes sense if you were to use them as keys in the new Map and Set objects...but I again, I can't help but notice that I haven't felt their absence yet. Thanks for the reference about CL make-symbol . Is there a practical use for this we actually would spot in the wild, or do I need to go up on the mountain with a copy of The Art of the Metaobject Protocol ?

I had no idea what a Symbol even was until I stumbled upon alt - https://github.com/goatslacker/alt It's a small and simple code base, and much easier way to grok the concept than reading a book.

Good link. You can see the usage in the first few lines here:

https://github.com/goatslacker/alt/blob/master/src/alt.js

They seem to be being used mostly as immutable constants for readability--which kind of fits with normal use, right? I'm just trying to see if there's anything else here I'm missing.

Re: Tail-call optimization added to 6to5 compiler

#28

http://jsperf.com/tco/8

Thanks for sharing the benchmarks.

I'm not sure how 6to5, or any other transpiler, could do much better. The job these tools exist to do necessarily means they can't do better than what today's browsers' JS engines will support.

Presumably in due course browsers will provide ES6 natively and so be better able to optimise code that uses tail calls in this way. Still, it's important to realise that the 6to5 implementation is much slower, and more of a forward-compatible stepping stone if you need it than something to use routinely if you like a functional programming style.

Re: Tail-call optimization added to 6to5 compiler

#29
post #3

Earlier quoted context omitted.

Which parts of es6 would you call 'functional curious'?

With destructuring and tco, the only thing its really missing is pattern matching on multiple function bodies.

This is the single biggest thing I miss from Haskell when programming in other languages.

Pattern-matching and guards are crazy useful.

Re: Tail-call optimization added to 6to5 compiler

#30
post #17

Earlier quoted context omitted.

Tail call optimization is more than optimized tail recursion . Recur provides an explicit form of support for the latter, but not the former.

In practice recursion probably covers most of the cases where it matters. Corecursion could (if awkwardly) be converted into ordinary recursion.

No, it doesn't. Think about composition and partial application.
Post reply on HN