From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 9116EBC57 for ; Mon, 30 Aug 2010 19:09:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoCAFKCe0zRVdi0kGdsb2JhbACBRJExhUoBhzdDCBUBAQEBCQkMBxEDH6J/iSeCE4V5LohUAQEDBYUyBIFXgxiFGg X-IronPort-AV: E=Sophos;i="4.56,293,1280700000"; d="scan'208";a="57993694" Received: from mail-qy0-f180.google.com ([209.85.216.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Aug 2010 19:09:38 +0200 Received: by qyk31 with SMTP id 31so6658344qyk.18 for ; Mon, 30 Aug 2010 10:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kjidYJztplh7r4xAiLAqvfug3gliX6LHeImLTJZ3cbY=; b=K1P9S83lZq4Fy5z6y3CKl03iNGgM9jHJPg3yLlzAOrX4c00OYQkcuFHYe0Hq9CvLGx +1AIir0gj3ANWkAg75NlP3GswMLpjyWgdP2yqkUsXCOc5OmZwjVVNSTRlK/l9ZWZQdXN L6DLX9P90E/y+LGwyLBsAflcNpPBw7DhGKLZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nPfy9Y/RK/CDTIF0l5V+J5xKSikykb3jdOlt6Vog8kssBqQ/3FLCHUvkNFBVHU6v1H WElfJR23hJ/Ru0f40KCgPuWtDCsolPv10495BHTMHYGOVAsAmU5T04jVc4IvLvVJNs65 mySBzg5Uu8Yrv0s5YO/1Z/ycJ2hYYDx84M6AY= MIME-Version: 1.0 Received: by 10.229.52.32 with SMTP id f32mr3217797qcg.265.1283188177646; Mon, 30 Aug 2010 10:09:37 -0700 (PDT) Received: by 10.229.218.19 with HTTP; Mon, 30 Aug 2010 10:09:37 -0700 (PDT) In-Reply-To: <026901cb485b$ff1b8ad0$fd52a070$@com> References: <026901cb485b$ff1b8ad0$fd52a070$@com> Date: Tue, 31 Aug 2010 03:09:37 +1000 Message-ID: Subject: Re: [Caml-list] Llama Light: a simple implementation of Caml From: ivan chollet To: Jon Harrop Cc: Jeremy Bem , caml-list List Content-Type: multipart/alternative; boundary=0016367d5ba882673f048f0d872d X-Spam: no; 0.00; recursion:01 pointers:01 run-time:01 compiler:01 recursion:01 cheers:01 pointers:01 typechecker:01 ocaml:01 typechecker:01 runtime:01 bytecode:01 compiler:01 bug:01 toplevel:01 --0016367d5ba882673f048f0d872d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 th= e > compiler because avoiding boxing gives huge performance gains and makes i= t > much easier to write a performant garbage collector. You=92ll need to > sacrifice polymorphic recursion though, which you probably already have > anyway=85 > > > > 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 ho= w > 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 t= he > 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 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 "ty= pe > 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 compil= er > 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 > 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 =3D 2 > > # let x =3D 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 =3D 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 tha= t > have polymorphic type annotations are generalised, while in your system i= t > is not possible to force generalisation. > > > > I had a look at the typer, and it's indeed rather simple; it seems it wou= ld > be quite simple to implement generalized let (when encountering annotatio= ns > or with a different syntaxic construct : "letg .. =3D .. in ..."), but th= e > 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 > > > --0016367d5ba882673f048f0d872d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable clearly didn't plan to support polymorphic recursion in any way. I don&= #39;t even plan to support lexical scoping...
As for data representation= I'm actually boxing everything except ints and function pointers. I fo= und out that it leads to the simplest design, which is appropriate for a pr= oject that I don't want to take me more than a few days.


On Tue, Aug 31, 2010 at 1:57 AM, Jon Har= rop <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=92ll need to sacrifice polymorphic recursion though, which you probably already have anyway=85

=A0

Cheers,

Jon.

=A0

F= rom: caml-list-bounce= s@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 Cam= l

=A0

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 an= d 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 theo= retical motivations of works like yours!


On Mon, Aug 30, 2010 at 2:37 AM, Jeremy Bem <jeremy1@gmail.com>= ; wrote:

bluestorm:

=A0

Thank you for the bug report. =A0The toplevel issue = has been fixed in the version now posted.

=A0

Do you see a nice way to add let-generalization with= out reintroducing "type levels"? =A0I was pleased to remove those.

=A0

Ivan:

=A0

It was originally forked from Caml Light but now inc= ludes more code from OCaml. =A0The 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.

=A0

-Jeremy

=A0

On Sun, Aug 29, 2010 at 6:52 AM, bluestorm <bluestorm.dylc@gma= il.com> wrote:

When using the toplevel, declaration phrases fail (l= ooks like a linking problem), but expressions work as intented :

$ llama

=A0=A0 =A0 =A0 =A0Llama Light version 0.0828

# 1 + 1;;

- : int =3D 2

# let x =3D 1 + 1;;

Error: Reference to undefined global `Toploop'

=A0

I made my tests using "llamac -i foo.ml".

=A0


I found it startling that the most important difference to my eyes are buri= ed, on the web page, under lines of relatively boring documentation :

In Llama Light (and in contrast to other Caml implementations):

=A0

- let=A0does not generalize.

- Phrases are generalized immediately. In particular= , "let foo =3D ref []" does not typecheck.

- The value restriction is not=A0relaxed. (This is similar to Caml Light.)

=A0

These choices simplify the implementation while havi= ng relatively little impact on the user.

=A0

You cite the "Let Should Not Be Generalised&quo= t; paper. There is however a difference in your application of the maxim : in = the paper, local let that have polymorphic type annotations are generalised, wh= ile in your system it is not possible to force generalisation.

=A0

I had a look at the typer, and it's indeed rathe= r simple; it seems it would be quite simple to implement generalized let (when encounter= ing annotations or with a different syntaxic construct : "letg .. =3D .. i= n ..."), but the added complexity is equivalent to adding let generaliza= tion by default.

=A0

Is the presence of let-generalization a real issue i= n your work ?

=A0


_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

=A0


--0016367d5ba882673f048f0d872d--