> 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
;t
> assume 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:
> >>
> >
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
cur does), but means you can't
>> assume 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:
>>
>> &
VM 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.
> >
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.
>
>
timized.
-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? Thanks.
>
> Dale
>
> --
> You r
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@google
12 matches
Mail list logo
