Difference between revisions of "Why Tailcalls"
From JVMLangSummit
Jump to navigationJump to search| Line 14: | Line 14: | ||
=== guaranteed disposal of stack-frame === | === guaranteed disposal of stack-frame === | ||
Clojure needs workarounds to avoid floating garbage | Clojure needs workarounds to avoid floating garbage | ||
| + | public static int count(Object o) { | ||
| + | if (o instanceof Counted) | ||
| + | return ((Counted) o).count(); | ||
| + | return countFrom(Util.ret1(o, o = null)); | ||
| + | } | ||
| + | static public Object ret1(Object ret, Object nil) { return ret; } | ||
=== Kōan === | === Kōan === | ||
Revision as of 11:49, 28 July 2010
Are tailcalls fated to come in second place on every feature priority list?
Let's gather the use cases and consider the implementation.
(Note: This page is about "hard tail calls" as defined in the Rose blog. Soft TCO is already in many compilers, but does not have a strong effect on software architecture.)
Contents
use cases
multi-core task distribution
(Doug Lea) chaining task execution; without tail calls you blow the stack needlessly
languages with guaranteed TCO
These are languages with functional patterns, including Scheme, Scala, F#. Seph also aims to give this guarantee.
guaranteed disposal of stack-frame
Clojure needs workarounds to avoid floating garbage
public static int count(Object o) {
if (o instanceof Counted)
return ((Counted) o).count();
return countFrom(Util.ret1(o, o = null));
}
static public Object ret1(Object ret, Object nil) { return ret; }
Kōan
Tail call... Booty call... More than a coincidence? You decide.
