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
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?
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).
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
--
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
--
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
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
11 matches
Mail list logo
