[Haskell-cafe] Lazy language on JVM/CLR
Tony Morris
NET CLR with FFI to .NET/Java libraries. I foresee various problems but
none that are catastrophic; just often requiring a compromises,
sometimes very unattractive compromises. I have authored several
libraries in the same vain as pure, lazy programming to run on the JVM
in Java and Scala programming languages.
I expect others have forethought and perhaps even experimented with such
a language. Are there any dangers to be wary of that undo the entire
endeavour?
Thanks for any insights.
--
Tony Morris
http://tmorris.net/
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
John Meacham
> I have hypothesised a pure, lazy language on the JVM and perhaps the
> none that are catastrophic; just often requiring a compromises,
> sometimes very unattractive compromises. I have authored several
> libraries in the same vain as pure, lazy programming to run on the JVM
> in Java and Scala programming languages.
Yes, I have done some design work on a JVM back end for JHC, which seems
quite doable and has been on my todo list for a while.
> I expect others have forethought and perhaps even experimented with such
> a language. Are there any dangers to be wary of that undo the entire
> endeavour?
There have been a couple papers published on it, the main sticking point
seems to be tail call elimination. When targeting real hardware you
always had the option of dropping to assembly to do a direct jump, but
there isn't an equivalent in the JVM. If you look up tail call + jvm you
will probably get a few hits. I believe there are even a couple haskell
specific papers on the issue.
If you just want something that works and isn't necessarily the most
efficient, you can do something like implement the G-machine in java,
you would then have a VM on a VM though.. but it would work and be
straightforward.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Marcin Kosiba
> On Tue, Feb 09, 2010 at 10:42:26AM +1000, Tony Morris wrote:
>> I expect others have forethought and perhaps even experimented with such
>> a language. Are there any dangers to be wary of that undo the entire
>> endeavour?
>
> There have been a couple papers published on it, the main sticking point
> seems to be tail call elimination. When targeting real hardware you
> always had the option of dropping to assembly to do a direct jump, but
> there isn't an equivalent in the JVM. If you look up tail call + jvm you
> will probably get a few hits. I believe there are even a couple haskell
> specific papers on the issue.
>
remember reading that F# relies on such a mechanism. AFAIK you just
need to mark the bytecode as "to be optimized" and the runtime does
that for you.
Tom Lokhorst
the Utrecht Haskell Compiler (UHC) [1].
That was a one-month project for a seminar at Utrecht University, and
the backend is far from being complete. But we did make some
interesting observations.
A particular caveat of the UHC is that it does whole program analysis,
so we had access to the entire program and all libraries at compile
time.
A benefit of using the CLR was that it does support tail calls. So a
mutual recursive function definition can loop a million times without
creating a stack overflow.
Our main problem (in efficiency) was lazy evaluation, not knowing the
difference between an evaluated `int` and a possible thunk
`Lazy<int>`. That meant we had to wrap _everything_ in a layer of
indirection, e.g.:
> add :: Int -> Int -> Int
> add x y = x + y
> add 2 4
Becomes something equivalent to:
> public int add(Lazy<int> x, Lazy<int> y)
> {
> return x.Force() + y.Force();
> }
> add(new Lazy(() => 2), new Lazy(() => 4));
Having a strictness analyser would have helped tremendously.
Also, I wonder if there is some efficient way of implementing the Lazy
class, perhaps by having the Force method using runtime code
generation to override itself. I don't know if this is possible, but I
vaguely remember the Dynamic Language Runtime on .NET doing something
like that.
I find this an interesting topic, so when you do have something more,
please let us know on this list.
- Tom Lokhorst
[1]: http://tom.lokhorst.eu/ehc/clr/ehc-clr-handout.pdf
On Tue, Feb 9, 2010 at 1:42 AM, Tony Morris <tonym...@gmail.com> wrote:
> I have hypothesised a pure, lazy language on the JVM and perhaps the
> .NET CLR with FFI to .NET/Java libraries. I foresee various problems but
Sittampalam, Ganesh
> Also, I wonder if there is some efficient way of implementing the
> Lazy class, perhaps by having the Force method using runtime code
> generation to override itself. I don't know if this is possible, but
> I vaguely remember the Dynamic Language Runtime on .NET doing
> something like that.
NET 4 (final release due in the next few months) will have a built-in
lazy type.
Ganesh
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
Tim Wawrzynczak
http://openquark.org/Open_Quark/Welcome.html
It's a pure, lazy language for the JVM. I haven't used it myself, but I
would imagine that
it would have a Java FFI.
Cheers,
- Tim
On Mon, Feb 8, 2010 at 6:42 PM, Tony Morris <tonym...@gmail.com> wrote:
> I have hypothesised a pure, lazy language on the JVM and perhaps the
> .NET CLR with FFI to .NET/Java libraries. I foresee various problems but
Edward Kmett
>
> > I expect others have forethought and perhaps even experimented with such
> > a language. Are there any dangers to be wary of that undo the entire
> > endeavour?
>
> There have been a couple papers published on it, the main sticking point
> seems to be tail call elimination. When targeting real hardware you
> always had the option of dropping to assembly to do a direct jump, but
> there isn't an equivalent in the JVM. If you look up tail call + jvm you
> will probably get a few hits. I believe there are even a couple haskell
> specific papers on the issue.
>
One of the easiest approaches to this comes from the scheme folks and I've
been able to employ it fairly effectively in toy compilers. It doesn't
require anything from the host language except exceptions and you can use it
to evaluate spineless tagless g-machine frames mostly on the native/VM stack
fairly easily. The biggest problem is the generated code bloat factor of
about 2-3x.
http://www.ccs.neu.edu/scheme/pubs/stackhack4.html
http://www.cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/
-Edward Kmett
Chris Eidhof
-chris
Tim Wawrzynczak
closely. I wonder how it deals with I/O, then? I don't see anything like
Haskell's monads or Clean's uniqueness typing... but at a closer look it
does appear to have an excellent Java FFI.
Tom Davies
On 10/02/2010, at 2:52 AM, Tim Wawrzynczak wrote:
> Oops, you're right. It's not pure. Mea cupla for not reading more closely. I wonder how it deals with I/O, then? I don't see anything like Haskell's monads or Clean's uniqueness typing... but at a closer look it does appear to have an excellent Java FFI.
>
> On Tue, Feb 9, 2010 at 9:44 AM, Chris Eidhof <ch...@eidhof.nl> wrote:
> I don't think it's pure. I would definitely use a pure language on the JVM, but IIRC Open Quark / Cal is an impure language. For example, from the library documentation: "printLine :: String -> ()".
CAL is pure as long as you don't call Java functions with side effects, or functions like printLine -- rather like avoiding unsafePerformIO in Haskell. For my experimentation I use my own IO monad implementation, but you can generally use `seq` to control when IO happens.
The Java FFI is good, although arguably verbose.
Tom_______________________________________________