If you can keep it agnostic wrt boxing then you should be able
to plug it into HLVM easily for much faster numerics and parallelism.
Cheers,
Jon.
From: ivan chollet
[mailto:ivan.chollet@gmail.com]
Sent: 30 August 2010 18:10
To: Jon Harrop
Cc: Jeremy Bem; caml-list List
Subject: Re: [Caml-list] Llama Light: a simple implementation of Caml
clearly didn't plan to support
polymorphic recursion in any way. I don't even plan to support lexical
scoping...
As for data representation I'm actually boxing everything except ints and
function pointers. I found out that it leads to the simplest design, which is
appropriate for a project that I don't want to take me more than a few days.
On Tue, Aug 31, 2010 at 1:57 AM, Jon Harrop <jonathandeanharrop@googlemail.com>
wrote:
Try to remove all assumptions of uniform
run-time representation from the compiler because avoiding boxing gives huge
performance gains and makes it much easier to write a performant garbage collector.
You’ll need to sacrifice polymorphic recursion though, which you probably
already have anyway…
Cheers,
Jon.
From: caml-list-bounces@yquem.inria.fr [mailto:caml-list-bounces@yquem.inria.fr]
On Behalf Of ivan chollet
Sent: 30 August 2010 11:57
To: Jeremy Bem
Cc: caml-list List
Subject: Re: [Caml-list] Llama Light: a simple implementation of Caml
OK.
This looks nice and I would be pleased if you could put a few pointers or
explanations on your webpage about your typechecker implementation and how it
differs with OCaml typechecker.
I will get some free time this week and to implement yet another runtime and
bytecode compiler from scratch. Not sure if it will be completed at the end of
the week, but i'll be definitely interested to know more about the theoretical
motivations of works like yours!
On
Mon, Aug 30, 2010 at 2:37 AM, Jeremy Bem <jeremy1@gmail.com> wrote:
bluestorm:
Thank
you for the bug report. The toplevel issue has been fixed in the version
now posted.
Do
you see a nice way to add let-generalization without reintroducing "type
levels"? I was pleased to remove those.
Ivan:
It
was originally forked from Caml Light but now includes more code from OCaml.
The typechecker is mostly original code at this point; the compiler is
OCaml's with minimal changes to accommodate the new typechecker; the runtime is
almost identical to OCaml's.
-Jeremy
On
Sun, Aug 29, 2010 at 6:52 AM, bluestorm <bluestorm.dylc@gmail.com>
wrote:
When
using the toplevel, declaration phrases fail (looks like a linking problem),
but expressions work as intented :
$
llama
Llama Light version 0.0828
# 1 + 1;;
- : int = 2
# let x = 1 + 1;;
Error: Reference to undefined global `Toploop'
I
made my tests using "llamac -i foo.ml".
I found it startling that the most important difference to my eyes are buried,
on the web page, under lines of relatively boring documentation :
In
Llama Light (and in contrast to other Caml implementations):
- let does not generalize.
- Phrases are generalized immediately. In particular, "let foo = ref []" does not typecheck.
- The value restriction is not relaxed. (This is similar to Caml Light.)
These choices simplify the implementation while having relatively little impact on the user.
You
cite the "Let Should Not Be Generalised" paper. There is however a
difference in your application of the maxim : in the paper, local let that have
polymorphic type annotations are generalised, while in your system it is not
possible to force generalisation.
I
had a look at the typer, and it's indeed rather simple; it seems it would be
quite simple to implement generalized let (when encountering annotations or
with a different syntaxic construct : "letg .. = .. in ..."), but the
added complexity is equivalent to adding let generalization by default.
Is
the presence of let-generalization a real issue in your work ?
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs