Claus Reinke wrote:
|Basically, the JVM lacks a native ability to do tail calls. It does
|not have an instruction to remove/replace a stack frame without
|executing an actual return to the calling method/function.
There is a conflict between preserving stack layout and efficient
tail calls.
Incidentally, I am looking for someone well versed in the JVM who wants
to help spearhead a JVM back end for jhc.
I would love to see this! With the current advent of all those languages
targeting at the JVM (Groovy, Scala, Clojure) I think a JVM backend for a
Haskell compiler could,
Although I don't know what the current JVM lacks to properly act as a
functional backend, it appears that JVM 1.7 will be at least better
suitable to support dynamic languages.
See: The Da Vinci Machine Project
http://openjdk.java.net/projects/mlvm/
Arvid
On Fri, Jun 26, 2009 at 2:09 PM, Timo
On 26 Jun 2009, at 14:09, Timo B. Hübel wrote:
And here comes my question: If there is anybody with proper
knowledge about
this issue, I would really like to know what are those things that are
missing? For example, Clojure lacks proper tail recrusion
optimization due to
some missing
There has been a scheme with tail recursion on the JVM for a long time
IIRC. SISC right?
At least I am fairly certain it does.
On Friday, June 26, 2009, Timo B. Hübel t...@gmx.info wrote:
Incidentally, I am looking for someone well versed in the JVM who wants
to help spearhead a JVM back end
Hi Timo,
On Fri, Jun 26, 2009 at 5:09 AM, Timo B. Hübel t...@gmx.info wrote:
Incidentally, I am looking for someone well versed in the JVM who wants
to help spearhead a JVM back end for jhc.
I would love to see this! With the current advent of all those languages
targeting at the JVM
On Fri, Jun 26, 2009 at 7:12 AM, David Leimbach leim...@gmail.com wrote:
There has been a scheme with tail recursion on the JVM for a long time
IIRC. SISC right?
Ah SISC is interpreted. Clojure is compiled. At least that may be the key
difference to making it work or not.
At least I am
For example, Clojure lacks proper tail recrusion optimization due to
some missing functionality in the JVM. But does anybody know the
details?
|Basically, the JVM lacks a native ability to do tail calls. It does
|not have an instruction to remove/replace a stack frame without
|executing
Since the JVM doesn't seem to support tail call optimization, I
suppose one could could directly manipulate the bytecodes generated by
jhc to do TCO.
One challenge would be the garbage collector, since Haskell and Java
have very different working sets of what is still being used.
--
Regards,
JVM 7 has tail calls, and if you don't want to wait for that, goto
works perfectly well for self-recursive functions. Other techniques
can deal with mutual recursion, albeit at the cost of performance.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
Maybe the JVM could be abused so that all of the haskell code is
within one function, so as to avoid java's notion of a function
boundary and implement our own using just goto? Or does the JIT
operate on entire functions at a time?
On Fri, Jun 26, 2009 at 1:23 PM, John A. De Goesj...@n-brain.net
On Fri, Jun 26, 2009 at 10:44 AM, Daniel Peeblespumpkin...@gmail.com wrote:
Maybe the JVM could be abused so that all of the haskell code is
within one function, so as to avoid java's notion of a function
boundary and implement our own using just goto? Or does the JIT
operate on entire
JVM 7 has tail calls,
Source, please? JSR-292 seems the most likely candidate so far,
and its draft doesn't seem to mention tail calls yet. As of March
this year, the people working on tail calls for mlvm [1], which
seems to be the experimentation ground for this, did not seem to
expect any
I don't have a source, but I know tail calls have been implemented (in
a patch) and tested, and at the JVM Summit everyone was saying this
was definitely going to be released in JVM 7.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|
On Fri, Jun 26, 2009 at 03:26:34PM +0200, Maarten Hazewinkel wrote:
On 26 Jun 2009, at 14:09, Timo B. Hübel wrote:
And here comes my question: If there is anybody with proper knowledge
about
this issue, I would really like to know what are those things that are
missing? For example,
2009/06/24 Greg Meredith lgreg.mered...@biosimilarity.com:
Better support for std Haskell syntax
What does this mean, actually? Better support for standard
Haskell syntax than what?
--
Jason Dusek
___
Haskell-Cafe mailing list
Jason,
CAL's syntax is not std Haskell syntax.
Best wishes,
--greg
On Thu, Jun 25, 2009 at 11:10 AM, Jason Dusek jason.du...@gmail.com wrote:
2009/06/24 Greg Meredith lgreg.mered...@biosimilarity.com:
Better support for std Haskell syntax
What does this mean, actually? Better support
Incidentally, I am looking for someone well versed in the JVM who wants
to help spearhead a JVM back end for jhc. If someone is interested,
please join the j...@haskell.org mailing list. Jhc already cross compiles
to a number of architectures so it may be an easier task than a ghc
port. (or good
Hello,
I stumbled upon your discussion on haskell-cafe and this theme seems to pop
up one time or another. If someone is interested, I have some Java
code for compiling Haskell98 to bytecode that I would be more than
willing to share. It is not in the best shape and does not implement
all of
Hi,
up one time or another. If someone is interested, I have some Java
code for compiling Haskell98 to bytecode that I would be more than
willing to share. It is not in the best shape and does not implement
You might also be interested in:
http://www.brianweb.net/personal/blog/entry.php?id=18
Questions about Haskell for JVM or .NET was asked quite often and it
is really interesting question. Since the JVM and .NET machines have a
lot of common if there was a compiler for one of them then it can
retargeted to the other quite easily. The major problem with such
compilers is the
21 matches
Mail list logo
