caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jonathandeanharrop@googlemail.com>
To: "'ivan chollet'" <ivan.chollet@gmail.com>,
	"'Jeremy Bem'" <jeremy1@gmail.com>
Cc: "'caml-list List'" <caml-list@yquem.inria.fr>
Subject: RE: [Caml-list] Llama Light: a simple implementation of Caml
Date: Mon, 30 Aug 2010 16:57:04 +0100	[thread overview]
Message-ID: <026901cb485b$ff1b8ad0$fd52a070$@com> (raw)
In-Reply-To: <AANLkTi=ptf2AnYV+1e66JHtwzbWQQvaUtdNvPbEsHJiA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

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

 


[-- Attachment #2: Type: text/html, Size: 10522 bytes --]

  reply	other threads:[~2010-08-30 15:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-29  5:42 Jeremy Bem
2010-08-29 10:52 ` [Caml-list] " bluestorm
2010-08-29 16:37   ` Jeremy Bem
2010-08-29 18:42     ` Jeremy Bem
2010-08-30 10:57     ` ivan chollet
2010-08-30 15:57       ` Jon Harrop [this message]
2010-08-30 17:09         ` ivan chollet
2010-08-30 17:39           ` Jon Harrop
2010-09-01  6:21             ` ivan chollet
     [not found]     ` <AANLkTikbSKCiXVMNsp9DxkW1FxzTFTxDhE=gWPxnqyJ3@mail.gmail.com>
     [not found]       ` <AANLkTi=dVrqaMchpvPsipasevtNn4Wz_6MWq6nUXjD8E@mail.gmail.com>
     [not found]         ` <AANLkTi=G2e_6Tn5cOQ5OOPhTLPk6Lsqx2hazt+O+H7gH@mail.gmail.com>
2010-08-30 20:49           ` Jeremy Bem
2010-08-29 13:00 ` ivan chollet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='026901cb485b$ff1b8ad0$fd52a070$@com' \
    --to=jonathandeanharrop@googlemail.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=ivan.chollet@gmail.com \
    --cc=jeremy1@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).