> 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
Thanks for the replies, that certainly clarified things!
On 3 August 2010 13:39, Rich Hickey wrote:
>
>
> On Aug 3, 2:19 am, Daniel Kersten 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 b
> 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
> 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
On Aug 3, 2:19 am, Daniel Kersten 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
> tail-call). Isn't this h
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
tail-call). Isn't this how its done in native compiled languages with TCO?
H
On 3 August 2010 04:16, Dan Kersten 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 through the usual JV
as Rich Hickey stated
question: Is it fundamentally impossible to do TCO on JVM due to
current JVM lack of primitives to do so? Would TCO ever be possible on
the JVM without a new JVM design?
rhickey: TCO is easy if you are an interpreter - see SISC Scheme.
Using Java's call stack, the JVM would h
Why can't the clojure bytecode compiler hand-perform this like
functional languages do when compiling to native code? Is it to keep
the clojure compiler fast (for dynamic runtime compilation), since
performing tail call optimisation presumably requires a bunch of extra
checks and more complex code
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 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 receiv
It means that the JVM doesn't look at method calls and figure out that they're
in tail call position and optimize them. You can hand-write code that performs
a goto in a tight loop (like recur does), but means you can't assume that
method calls in general will be tail call optimized.
-Fred
--
11 matches
Mail list logo
