On 3 August 2010 04:16, Dan Kersten dkers...@gmail.com wrote:
Why can't the clojure bytecode compiler hand-perform this like
functional languages do when compiling to native code?
Because bytecode attempting to manipulate the stack and jump around
(unrestricted goto-like) in other ways than
questions answers.
On Aug 2, 2010, at 4:09 PM, Dale wrote:
The JVM has an unconditional goto opcode and the ability to re-bind
function parameters, so why no tail-call optimization? Thanks.
Dale
--
You received this message because you are subscribed to the Google
Groups
On Aug 3, 2:19 am, Daniel Kersten dkers...@gmail.com wrote:
Can one not detect that a recursive call is a tail call and then transform
the AST so that its iterative instead - ie, not use the stack besides for
initial setup of local variables (which then get reused in each recursive
Interestingly, [Erjang][1] (a port of Erlang to the JVM) apparently
performs TCO while claiming to stay reasonably fast. The gimmick
I have never done extensive benchmarking of clojure, but given the
frequent mentions of use of '-server' in order to achieve specific
performance goals, I get the
When speaking about general TCO, we are not just talking about
recursive self-calls, but also tail calls to other functions. Full TCO
in the latter case is not possible on the JVM at present whilst
preserving Java calling conventions (i.e without interpreting or
inserting a trampoline etc).
Thanks for the replies, that certainly clarified things!
On 3 August 2010 13:39, Rich Hickey richhic...@gmail.com wrote:
On Aug 3, 2:19 am, Daniel Kersten dkers...@gmail.com wrote:
Can one not detect that a recursive call is a tail call and then
transform
the AST so that its iterative
Some people even prefer 'recur' to the redundant restatement of the
function name. In addition, recur can enforce tail-call position.
Rich
Because recur only takes you back to the innermost loop, sometimes I miss
the ability to jump back to some outer loop (or the overall function call).
The JVM has an unconditional goto opcode and the ability to re-bind
function parameters, so why no tail-call optimization? Thanks.
Dale
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note
--
Science answers questions; philosophy questions answers.
On Aug 2, 2010, at 4:09 PM, Dale wrote:
The JVM has an unconditional goto opcode and the ability to re-bind
function parameters, so why no tail-call optimization? Thanks.
Dale
--
You received this message because you
the jvm goto's only can jump around inside method bodies, so it is a
very restricted goto
On Mon, Aug 2, 2010 at 2:09 PM, Dale dpar...@ptd.net wrote:
The JVM has an unconditional goto opcode and the ability to re-bind
function parameters, so why no tail-call optimization? Thanks.
Dale
function parameters, so why no tail-call optimization? Thanks.
Dale
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please
that method calls in general will be tail call optimized.
-Fred
--
Science answers questions; philosophy questions answers.
On Aug 2, 2010, at 4:09 PM, Dale wrote:
The JVM has an unconditional goto opcode and the ability to re-bind
function parameters, so why no tail-call optimization
12 matches
Mail list logo
