On Thu, Apr 2, 2009 at 10:15 AM, Ola Bini <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > John Cowan wrote: > > > On Thu, Apr 2, 2009 at 10:36 AM, kirk <[email protected] > > <mailto:[email protected]>> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
