Thanks. I will keep that it mind and might look into it one day or another.

Ivan


On Tue, Aug 31, 2010 at 3:39 AM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:

>  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
>
>
>
>
>