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 E780EBC57 for ; Mon, 30 Aug 2010 19:39:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQCAFuJe0zRVde0mWdsb2JhbACBRJEzgU6DfAGHeggVAQEBAQEICwoHESKjPos6AQWPAAEEhTeBW4MY X-IronPort-AV: E=Sophos;i="4.56,294,1280700000"; d="scan'208,217";a="57994826" Received: from mail-ey0-f180.google.com ([209.85.215.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Aug 2010 19:39:44 +0200 Received: by eya25 with SMTP id 25so4131948eya.39 for ; Mon, 30 Aug 2010 10:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=H5umcyfu3gGw1TAGruzGzEmPhsbbXGxTNeLQvYw76pg=; b=ha1SN0KCiPDitkeTG/msNNtfOfxydRicxQ7BtnKXBUVPWH2YzLtJ6AyjNnOw8wKdcr n1lIzUGBFNquE3S1aZU7xdwKAHsdToxlttRAzr4wu0ZiwM09SDCKV+uyR5N9BrsjOek4 XxD9qHhrvsdOTTTLQtBaMN29FJY4FudsEN+nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:x-mailer:thread-index :content-language; b=LhGqnqc9fH3whcd8d/tUcDsxb9FB6u8GzFqrwpFhtt18yVhqjVTwkWTDWBGhOTaDqb /hMmnPoigKILHK1p1vwvPhOGh63qvEIWUjHvfWu2wvKvWo2MzVXAnJd7A88+U3/3+iJ2 94C21zgD+DW+VPqtGeCqoF0SrxwxKni3djyB4= Received: by 10.216.188.81 with SMTP id z59mr5180607wem.106.1283189982370; Mon, 30 Aug 2010 10:39:42 -0700 (PDT) Received: from WinEight ([87.113.136.121]) by mx.google.com with ESMTPS id n40sm4621787weq.29.2010.08.30.10.39.39 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 10:39:41 -0700 (PDT) From: Jon Harrop To: "'ivan chollet'" , "'Jon Harrop'" Cc: "'Jeremy Bem'" , "'caml-list List'" References: <026901cb485b$ff1b8ad0$fd52a070$@com> In-Reply-To: Subject: RE: [Caml-list] Llama Light: a simple implementation of Caml Date: Mon, 30 Aug 2010 18:39:20 +0100 Organization: Flying Frog Consultancy Message-ID: <027401cb486a$48511e00$d8f35a00$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0275_01CB4872.AA158600" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActIZiCKqvJUmmSVSaG6vG4Vv2+0WwAAzKcA Content-Language: en-gb 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 This is a multi-part message in MIME format. ------=_NextPart_000_0275_01CB4872.AA158600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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 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 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 ------=_NextPart_000_0275_01CB4872.AA158600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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@goog= lemail.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

 <= /o:p>

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:

 <= /o:p>

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

 <= /o:p>

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

 <= /o:p>

Ivan:

 <= /o:p>

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.

 <= /o:p>

-Jeremy

 <= /o:p>

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 =3D 2

# let x =3D 1 + 1;;

Error: Reference to undefined global `Toploop'

 <= /o:p>

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

 <= /o:p>


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

 <= /o:p>

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

 <= /o:p>

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

 <= /o:p>

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.

 <= /o:p>

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 .. =3D .. in = ..."), but the added complexity is equivalent to adding let generalization by = default.

 <= /o:p>

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

 <= /o:p>


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

 <= /o:p>

 

------=_NextPart_000_0275_01CB4872.AA158600--