Forgot to mention Scala 2.8.0 will probably also support explicit trampolining.
--j On Thu, Apr 2, 2009 at 11:56 AM, Jorge Ortiz <jorge.or...@gmail.com> wrote: > On Thu, Apr 2, 2009 at 10:15 AM, Ola Bini <ola.b...@gmail.com> wrote: > >> >> Bradford Cross wrote: >> > What is the current state of the art for language implementers working >> > around these issues (tail calls, continuations, etc) in Clojure, >> > Scala, JRuby, etc? >> > >> > I would imagine people are maintaining their own stacks? stacks and >> > hacks. :-) Sounds like Dr Seuss...I will not hack upon your stack, >> > i'll hack my stack to get you back. >> > >> > We have talked about the fact that certain programs are invalid >> > without TCO because they will overflow the stack - true enough. >> > >> > Does anyone have any crude benchmarks re the perf overhead of doing >> > these things in hand rolled stacks vs. at the byte code level. I have >> > to imagine it is massive for certian classes of programs. >> No one is doing hand rolled stacks. Clojure does explicit trampolining - >> but that is a very coarse and limited way of doing it. Scala removes >> tail calls where it can be statically transformed into iteration, but >> doesn't give any guarantees. Ruby has never had TCO's and JRuby uses the >> Java stack too. >> > > Scala 2.8.0 (due out later this year) will add a @tailrec annotation that > produces a compile error if the annotated method can't be statically > transformed into iteration when tail-called. > > SISC is one of the few implementations that do full TCO. There are >> basically a few variations on how to do it. CPS is common, trampolining >> works too. You can also have your own bytecode engine with your own stack. >> >> The overhead of all of these approaches are pretty severe on the JVM >> since the usage pattern is data driven and far away from how regular >> Java code looks like. But the most severe problem with it is that all of >> these approaches make it much hard to do calls into Java methods. >> >> Cheers >> >> > >> > On Thu, Apr 2, 2009 at 9:59 AM, kirk <kirk.pepperd...@gmail.com >> > <mailto:kirk.pepperd...@gmail.com>> wrote: >> > >> > >> > John Cowan wrote: >> > > On Thu, Apr 2, 2009 at 10:36 AM, kirk <kirk.pepperd...@gmail.com >> > <mailto:kirk.pepperd...@gmail.com>> wrote: >> > > >> > >> why do they have to be exposed? Isn't tail recursion and >> > implementation >> > >> detail? And an optimization at that? >> > >> >> > > >> > > No. >> > > >> > > Being able to rely on tail recursion is not an implementation >> > detail; >> > > Scheme programmers routinely write programs that tail-call >> > heavily and >> > > would blow up without it. A state machine implementation where >> > state >> > > transition codelets, expressed as functions, are tail-called by >> the >> > > dispatcher and tail-call it in turn is a classic example. >> "Lambda: >> > > the ultimate goto." >> > > >> > Understood, that said I think Patrick hit the nail on the head. >> > > And since Java exposes the call stack via Exception#fillInStack, >> the >> > > *presence* of tail recursion is unfortunately not an >> implementation >> > > detail either. >> > > >> > I would humbly disagree with this last statement. >> > >> > Regards, >> > Kirk >> > >> > >> > >> > >> > >> > > >> >> >> -- >> Ola Bini (http://olabini.com) >> Ioke creator (http://ioke.org) >> JRuby Core Developer (http://jruby.org) >> Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) >> Practical JRuby on Rails (http://apress.com/book/view/9781590598818) >> >> "Yields falsehood when quined" yields falsehood when quined. >> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
