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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 75325BC57 for ; Wed, 1 Sep 2010 08:21:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArICAKqNfUzRVdg0kGdsb2JhbACBQ5FKhVABh3kIFQEBAQEJCQwHEQMfo2mJLoIVhlIuiFQBAQMFhTQEgVeDG4Uf X-IronPort-AV: E=Sophos;i="4.56,302,1280700000"; d="scan'208";a="66488368" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Sep 2010 08:21:36 +0200 Received: by qwi4 with SMTP id 4so87558qwi.39 for ; Tue, 31 Aug 2010 23:21:36 -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=joGwhzjFKmJ9NbuZKJpQrwM1HIgzj9cEAbjrYXmmQnk=; b=oMFbg7t0lPVjrHfxDc8dnfWJujToSMFBAKEeABPiRYuOm1XrTGtuUsDHf4JSrAurMl V7enX2UywrOtJ9r+iusU99Y1NPHIucW/x2eELFhhBaZqaheqPs7NpuYMbpnMYIXkVtqH iorMycA25BhTbffQo9hDq4QvTqTtKcm1wqOo8= 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=uVRgcycSzSdVwRhCz65Ff376dYCS3DH73DdkgACELPgh3b+CNcQc705oJ2MM3uGfCk eJQeTsbhUPBFVIUEbvdMIdyMIs763kKnOXhcuH7OSrgMIEkh3uGnvyyB7UWPPxJltc5w I8Ps0+fztzElfhtQ8GK2HJ4WXMYUhx/yz2AoA= MIME-Version: 1.0 Received: by 10.229.214.210 with SMTP id hb18mr5049422qcb.68.1283322094631; Tue, 31 Aug 2010 23:21:34 -0700 (PDT) Received: by 10.229.218.19 with HTTP; Tue, 31 Aug 2010 23:21:34 -0700 (PDT) In-Reply-To: <027401cb486a$48511e00$d8f35a00$@com> References: <026901cb485b$ff1b8ad0$fd52a070$@com> <027401cb486a$48511e00$d8f35a00$@com> Date: Wed, 1 Sep 2010 16:21:34 +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=0016361e83ba953c7a048f2cb515 X-Spam: no; 0.00; parallelism:01 cheers:01 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 --0016361e83ba953c7a048f2cb515 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 i= t > 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, whic= h > 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 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 > > > > > --0016361e83ba953c7a048f2cb515 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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.

=A0

Cheers,

Jon.

=A0

F= rom: ivan cholle= t [mailto:ivan.ch= ollet@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 Cam= l

=A0

clearly didn't pl= an 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 a= nd 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 <jonathan= deanharrop@googlemail.com> wrote:

Try to remove all assumptions of uniform run-time representation from the compiler because avoiding boxing gives hug= e performance gains and makes it much easier to write a performant garbage co= llector. 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 without reintroducing "ty= pe levels"? =A0I was pleased to remove those.

=A0

Ivan:

=A0

It was originally forked from Caml Light but now includes 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 ru= ntime is almost identical to OCaml's.

=A0

-Jeremy

=A0

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

=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 having relatively little impact o= n the user.

=A0

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 no= t possible to force generalisation.

=A0

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 annotations or with a different syntaxic construct : "letg .. =3D .. in ..."), b= ut the added complexity is equivalent to adding let generalization by default.

=A0

Is the presence of let-generalization a real issue in 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

=A0


--0016361e83ba953c7a048f2cb515--