As I understand it, the implementation of tail calls in OpenJDK is complete
but Sun are not adding this feature to their JVM. Is that correct?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
--~--~-~--~~~---~--~~
You received
See this thread:
http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html
(continues in postings through February). Prototyping is ongoing.
AFAIK it's not decided yet whether the JSR 292 expert group will
address this explicitly and seek to standardize on it.
HTH
Patrick
Jon Harrop wrote:
As I understand it, the implementation of tail calls in OpenJDK is complete
but Sun are not adding this feature to their JVM. Is that correct?
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs will support
them. If it were just up to Sun, it would probably go in (since I know I
want it and
Jon Harrop wrote:
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs will support
them. If it were just up to Sun, it would probably go in (since I
why do they have to be exposed? Isn't tail recursion and implementation
detail? And an optimization at that?
Why would others have to adopt? Not all have adopted CMS GC or survivor
spaces?
I believe the idea is to force/require a tail call optimization,
rather than just hoping a JVM
kirk wrote:
Jon Harrop wrote:
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs will support
them. If it were just up to Sun, it would
Patrick Wright wrote:
why do they have to be exposed? Isn't tail recursion and implementation
detail? And an optimization at that?
Why would others have to adopt? Not all have adopted CMS GC or survivor
spaces?
I believe the idea is to force/require a tail call optimization,
rather
On Thursday 02 April 2009 15:36:38 kirk wrote:
Jon Harrop wrote:
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs will support
them. If it were
Jon Harrop wrote:
On Thursday 02 April 2009 15:36:38 kirk wrote:
Jon Harrop wrote:
On Thursday 02 April 2009 15:09:12 Charles Oliver Nutter wrote:
It's not necessarily Sun's choice when it exhibits external behavioral
changes. Such changes must be standardized so all JVMs
Sun has recently shown willingness to introduce features -- even very
major ones -- into its JVM that are not necessarily supported by other
JVM vendors since they are not part of the Java 7 specification. The
specific feature I'm thinking of here is Jigsaw.
I can't comment as to whether Sun
Hi,
I see a lot of strawman arguments for standardization but I don't really
see anything with substance. I'm not against the standardization route
but I'm just not seeing the need to treat this any differently than
say.. a different GC implementation. How about Escape Analysis or the
On Thu, Apr 2, 2009 at 10:36 AM, kirk kirk.pepperd...@gmail.com 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
Kirk, this was pretty much my point. Sun are willing to introduce
major changes like Jigsaw without a JSR, so why not tail calls? Having
said that, if you write code that relies on either Jigsaw or tail
calls then you are locked into one JVM.
I also don't want to divert the thread onto Jigsaw. I
Hi Kirk,
On Thu, Apr 2, 2009 at 4:51 PM, kirk kirk.pepperd...@gmail.com wrote:
I see a lot of strawman arguments for standardization but I don't really
see anything with substance. I'm not against the standardization route
but I'm just not seeing the need to treat this any differently than
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
On 04/02/2009 07:31 AM, Jon Harrop wrote:
I want to make sure I've got my facts straight, both in order to make an
informed decision myself and to inform others accurately. Specifically, I am
considering diversifying into Scala and/or Clojure and I need to know whether
or not the elimination
On Thu, Apr 2, 2009 at 1:10 PM, Bradford Cross
bradford.n.cr...@gmail.com 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?
Clojure uses recur
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
On 04/02/2009 10:15 AM, Ola Bini wrote:
Scala removes tail calls where it can be statically transformed into
iteration,
but doesn't give any guarantees.
I should have mentioned that Kawa does this too, even when not
using the full-tail-elimination calling-convention. I assume
most Scheme
On Apr 2, 2009, at 1:14 PM, Jim Menard wrote:
On Thu, Apr 2, 2009 at 1:10 PM, Bradford Cross
bradford.n.cr...@gmail.com 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?
On Thu, Apr 2, 2009 at 10:15 AM, Ola Bini ola.b...@gmail.com 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
Forgot to mention Scala 2.8.0 will probably also support explicit
trampolining.
--j
On Thu, Apr 2, 2009 at 11:56 AM, Jorge Ortiz jorge.or...@gmail.com wrote:
On Thu, Apr 2, 2009 at 10:15 AM, Ola Bini ola.b...@gmail.com wrote:
Bradford Cross wrote:
What is the current state of the art for
Ben Evans wrote:
If I'm following this thread right, then what is really meant by TCO is
not JVM implementations are allowed to spot that a certain pattern of
bytecodes (eg 0xb6 0xXY 0xZW 0xb0) are a tail-call and MAY be optimised
by the JITter but a certain, not currently permitted,
On Thursday April 2 2009, Charles Oliver Nutter wrote:
...
Well, you can always build and release a binary yourself, since it's
GPLed...you just can't call it Java or JVM because it's not being
held to those standards. Would that make you comfortable enough to
run something like MLVM with
Randall R Schulz wrote:
On Thursday April 2 2009, Charles Oliver Nutter wrote:
...
Well, you can always build and release a binary yourself, since it's
GPLed...you just can't call it Java or JVM because it's not being
held to those standards. Would that make you comfortable enough to
run
On Thu, Apr 2, 2009 at 6:11 PM, Per Bothner p...@bothner.com wrote:
A number of JVM-based languages implement tail-call elimination.
The problem is that you have to compile your functions into a
different calling convention that the natural. which has some
performance cost, and complicates
Note that *recursive* tail calls at least theoretically can be optimized using
a jump -- basically
turning the entire method into a loop. I'm not sure if any language does this
currently (I'd be
surprised if they didn't), but it's at least possible.
~~ Robert.
Jon Harrop wrote:
On
Charles Oliver Nutter a écrit :
Randall R Schulz wrote:
On Thursday April 2 2009, Charles Oliver Nutter wrote:
...
Well, you can always build and release a binary yourself, since it's
GPLed...you just can't call it Java or JVM because it's not being
held to those standards. Would
Chas Emerick wrote:
In those rare circumstances where you need to write mutually-recursive
functions without consuming stack, clojure provides a trampoline
implementation (introduced last November here:
http://groups.google.com/group/clojure/browse_frm/thread/6257cbc4454bcb85)
.
Robert Fischer wrote:
Chas Emerick wrote:
In those rare circumstances where you need to write mutually-recursive
functions without consuming stack, clojure provides a trampoline
implementation (introduced last November here:
I'm still catching up on my reading. Thanks. :)
~~ Robert.
Jim White wrote:
Robert Fischer wrote:
Chas Emerick wrote:
In those rare circumstances where you need to write mutually-recursive
functions without consuming stack, clojure provides a trampoline
implementation (introduced
On Thursday 02 April 2009 20:19:14 Charles Oliver Nutter wrote:
Jon Harrop wrote:
The problem is not my building and installing a custom JDK and testing it
to make sure that it is reliable myself. The problem is that requiring
customers to do that is such a substantial barrier to adoption
Jon Harrop wrote:
You mean if I wanted to tinker with it? Sure, but there is little point in me
running it if my customers will not.
So you're really not looking for a solution then, unless it's someone
else (Sun) putting the work in to get it into a release, right?
Perhaps you could offer
On Thursday 02 April 2009 18:11:17 Per Bothner wrote:
Kawa supports two calling conventions, selected by a command-line
switch:
(1) The obvious one where a Scheme function call is translated to
a plain method call, with the methods return value being the Scheme
function's result.
(2) Full
On Thursday 02 April 2009 19:05:48 Chas Emerick wrote:
On Apr 2, 2009, at 1:14 PM, Jim Menard wrote:
On Thu, Apr 2, 2009 at 1:10 PM, Bradford Cross
bradford.n.cr...@gmail.com wrote:
What is the current state of the art for language implementers
working
around these issues (tail
On 04/02/2009 10:44 PM, Jon Harrop wrote:
When Java calls back into Kawa, where does Kawa get the current CallContext
from when it has not been passed in as the first argument?
The CallContext is a per-thread structure, stored in a ThreadLocal.
Passing the CallContext from caller to callee in
37 matches
Mail list logo
