-[= Mon, Aug 09, 2010 at 04:37:36PM +1000, ivan chollet ]----
> The exis= ting ocaml runtime is
> amazing but it's definitely not very comm= unity friendly and is in my opinion
> a bit hard to understand given the scarcity of design documents. A rea= l
> community project with real documentation might be interesting fo= r teaching
> purposes but also in production environments.
> If= enough people are interested, I'll be happy to contribute or to start<= br> > such a project.

Don't you think it would be a more profitab= le work to document the
existing runtime instead ?

-[ Mon, Aug 09, 2010 at 04:37:36PM +1= 000, ivan chollet ]----
> The existing ocaml runtime is
> amazi= ng but it's definitely not very community friendly and is in my opinion=
> a bit hard to understand given the scarcity of design documents. A rea= l
> community project with real documentation might be interesting fo= r teaching
> purposes but also in production environments.
> If= enough people are interested, I'll be happy to contribute or to start<= br> > such a project.

Don't you think it would be a more profitab= le work to document the
existing runtime instead ?

=A0=A0match x, y with

=A0=A0 =A0Foo a, Foo b -> a=3Db

=A0=A0| Goo a, Goo b -> a=3Db

=A0=A0| Foo a, Goo b=

= =A0=A0| Goo b, Foo a ->=A0string_of_int a =3D b

type go= o =3D foo / foo_equiv (* automatically creates goo_of_foo *)

let _ =3D assert (goo_of_foo (Foo 3) =3D goo_of_foo (Goo "3"= ))

This would require runtime support. =A0I= envision that every "goo" is a block whose tag is "Quotient= _tag" and which stores a "foo_equiv" closure in its first Ob= j field.

As it happens, this approach would dovetail with my pla= ns for an integrated proof assistant. =A0Of course it lacks the "conse= rvatism" I've been promoting :)

-Jeremy

--000325555ec6dac3c5048d9559c9-- 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 3B1A3BBAF for ; Thu, 12 Aug 2010 08:57:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMBAFc4Y0zRVdg0kGdsb2JhbACgMQgVAQEBAQkJDAcRAx+fMokQghKGGS6IVAEBAwWFNQSEXoQbYw X-IronPort-AV: E=Sophos;i="4.55,356,1278280800"; d="scan'208";a="65304838" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 12 Aug 2010 08:56:59 +0200 Received: by qwj8 with SMTP id 8so1281014qwj.39 for ; Wed, 11 Aug 2010 23:56:58 -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=Qf4VARG4Vh80Y33UKHRgfqBKxi5A6Y299E9AkOcuRnc=; b=KqyNatK9IDCVYeqFKmeqmvkDywiOmpF5nWT/q5LvnIH8w7aZL+I5oGAgxtyTbBX4jd JewSFFU6MEXhrHsz3lXo3JkfPzZz9cOPjAbhHpjrGtKc1SI2BXxEefD6mMNIpSA3eiXa liXedW8iGVw4fTUZ9RWDNeblOkhpCHcHhB3wE= 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=UHD8F6EQbfXU2b8H/gr0ltTKEcgESlJMliQPevwkFWlXRKL3bG6c3QkJ07eHUlEfqD YPGJf8yPZboeNePsNhJ3l9ggDAQvROE6DyiQiGqRLMgppx8Krj+g+5ablZll4WCKauJN nMm6YuEx/JKxJB4ThsKB7ullKBtMhmyCSAOgc= MIME-Version: 1.0 Received: by 10.229.189.211 with SMTP id df19mr10711547qcb.146.1281596218507; Wed, 11 Aug 2010 23:56:58 -0700 (PDT) Received: by 10.229.217.71 with HTTP; Wed, 11 Aug 2010 23:56:58 -0700 (PDT) In-Reply-To: <03fc01cb3957$c79e2800$56da7800$@com> References: <03fc01cb3957$c79e2800$56da7800$@com> Date: Thu, 12 Aug 2010 16:56:58 +1000 Message-ID: Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml? From: ivan chollet To: Jon Harrop Cc: caml-list@yquem.inria.fr, jeremy1@gmail.com Content-Type: multipart/alternative; boundary=0016363b887c5982e2048d9adf44 X-Spam: no; 0.00; bytecode:01 bytecode:01 ocaml:01 runtime:01 runtime:01 ocaml:01 coupling:01 compiler:01 jocaml:01 runtimes:01 kloc:01 compilation:01 native-code:01 cheers:01 coupling:01 --0016363b887c5982e2048d9adf44 Content-Type: text/plain; charset=ISO-8859-1 + HLVM, Moscow ML, MLTon, etc. Not too bad in my opinion. I checked your HLVM and it looks like a really nice project. I had heard about it before but to be honest it's hard to find information about its design. Maybe you should release the design documents publicly. It could be also an good incentive for people to subscribe to your journal. I looked at the source and I have to say i like it for its simplicity. What I dislike is that your bytecode runs on LLVM, which is a general purpose virtual machine, and because it's general purpose, the bytecode and thus the JIT is a lot more complicated than if the whole infrastructure was for ML and ML only. My personal opinion is that the idiosyncrasies of ML deserve more elegant than this complicated piece of code. And what i dislike is to debug big pieces of code like this myself (especially when there is no documentation like with OCaml). So after reading a few things about HLVM, what I have in mind is basically the same thing as you did, with only a few minor differences : - the project should have it's own runtime (with runtime i mean interpreter + garbage collector only) - no need for a JIT at the beginning - less emphasis on performance at the beginning - less emphasis on features (your project looks very ambitious in terms of supported features) - more emphasis on code safety (than ocaml at least, i don't like to see segmentation faults). LLVM is not that strong on debugging and code safety than some other VMs are. (that's just what i've heard and I might be plain wrong here, but i'm unable to check it myself because LLVM source code is too complicated for me) - more emphasis on simplicity and interfaces loosely coupling - a LOT more emphasis on being community friendly and providing design documents (for free...) Now I have to say that LLVM is an amazing project (so is HLVM), and if you need to have an ML implementation up quickly with good performance and lots of features supported, then I would admit that this is the only way to go at the moment. There is no way the community around ML in general and OCaml specifically would ever come up in the next 10 years with such a feature-rich runtime and compiler infrastructure. But now that VMs are becoming a commodity and there is a lot of literature and resources on the topic, it is also not very time consuming to pull something from the ground up. I would be interested to hear your opinion on this. On Wed, Aug 11, 2010 at 11:19 PM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > Ivan wrote: > > I have noted that there are now many implementation of OCaml. Namely : > > - caml light > > - jocaml > > - mincaml > > - your implementation ? > > etc. > > > > which means there is a lot of interest in implementing tools and runtimes > for ML. > > I'm not sure 3.5 implementations over 25 years is a "lot" of interest but > maybe if you add HLVM... ;-) > > > Well, now I'm thinking that the community should start a project like > Parrot (with JIT optionally) > > but dedicated to ML. > > I already did something like this called HLVM: > > http://www.ffconsultancy.com/ocaml/hlvm/ > > > The existing ocaml runtime is amazing but it's definitely not very > community friendly and is in my > > opinion a bit hard to understand given the scarcity of design documents. > > Feel free to ask me anything about HLVM's design. We have a dedicated > mailing list: > > https://lists.forge.ocamlcore.org/pipermail/hlvm-list/ > > > A real community project with real documentation might be interesting for > teaching purposes but also > > in production environments. > > HLVM might be interesting for teaching purposes because it is tiny (2kLOC) > and comprehensible whilst providing advanced features like JIT compilation > (for a native-code REPL!) and a multicore-capable garbage collector (in > only > 100LOC!). HLVM should also be suitable for production environments. > > I had actually forgotten about the mincaml project but mincaml's front-end > with HLVM's back-end sounds like a match made in heaven... > > Cheers, > Jon. > > > --0016363b887c5982e2048d9adf44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable + HLVM, Moscow ML, MLTon, etc.
Not too bad in my opinion.

I check= ed your HLVM and it looks like a really nice project. I had heard about it = before but to be honest it's hard to find information about its design.= Maybe you should release the design documents publicly. It could be also a= n good incentive for people to subscribe to your journal.
I looked at the source and I have to say i like it for its simplicity. What= I dislike is that your bytecode runs on LLVM, which is a general purpose v= irtual machine, and because it's general purpose, the bytecode and thus= the JIT is a lot more complicated than if the whole infrastructure=A0 was = for ML and ML only. My personal opinion is that the idiosyncrasies of ML de= serve more elegant than this complicated piece of code.
And what i dislike is to debug big pieces of code like this myself (especia= lly when there is no documentation like with OCaml).

So after readin= g a few things about HLVM, what I have in mind is basically the same thing = as you did, with only a few minor differences :
- the project should have it's own runtime (with runtime i mean interpr= eter + garbage collector only)
- no need for a JIT at the beginning
-= less emphasis on performance at the beginning
- less emphasis on featur= es (your project looks very ambitious in terms of supported features)
- more emphasis on code safety (than ocaml at least, i don't like to se= e segmentation faults). LLVM is not that strong on debugging and code safet= y than some other VMs are. (that's just what i've heard and I might= be plain wrong here, but i'm unable to check it myself because LLVM so= urce code is too complicated for me)
- more emphasis on simplicity and interfaces loosely coupling
- a LOT mo= re emphasis on being community friendly and providing design documents (for= free...)

Now I have to say that LLVM is an amazing project (so = is HLVM), and if you need to have an ML implementation up quickly with good= performance and lots of features supported, then I would admit that this i= s the only way to go at the moment. There is no way the community around ML= in general and OCaml specifically would ever come up in the next 10 years = with such a feature-rich runtime and compiler infrastructure.
But now that VMs are becoming a commodity and there is a lot of literature = and resources on the topic, it is also not very time consuming to pull some= thing from the ground up.
I would be interested to hear your opinion on = this.

On Wed, Aug 11, 2010 at 11:19 PM, Jon Ha= rrop <jonathandeanharrop@googlemail.com> wrote:

Ivan wrote:
> I have noted that there are now many implementation of OCaml. Namely :=
> - caml light
> - jocaml
> - mincaml
> - your implementation ?
> etc.
>
> which means there is a lot of interest in implementing tools and runti= mes
for ML.=A0

I'm not sure 3.5 implementations over 25 years is a "lot&quo= t; of interest but
maybe if you add HLVM... ;-)

> Well, now I'm thinking that the community should start a project l= ike
Parrot (with JIT optionally)
> but dedicated to ML.

I already did something like this called HLVM:

=A0= http://www.ffconsultancy.com/ocaml/hlvm/

> The existing ocaml runtime is amazing but it's definitely not very=
community friendly and is in my
> opinion a bit hard to understand given the scarcity of design document= s.

Feel free to ask me anything about HLVM's design. We have a dedic= ated
mailing list:

=A0https://lists.forge.ocamlcore.org/pipermail/hlvm-list/

> A real community project with real documentation might be interesting = for
teaching purposes but also
> in production environments.

HLVM might be interesting for teaching purposes because it is tiny (2= kLOC)
and comprehensible whilst providing advanced features like JIT compilation<= br> (for a native-code REPL!) and a multicore-capable garbage collector (in onl= y
100LOC!). HLVM should also be suitable for production environments.

I had actually forgotten about the mincaml project but mincaml's front-= end
with HLVM's back-end sounds like a match made in heaven...

Cheers,
Jon.

--0016363b887c5982e2048d9adf44-- 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 D1C17BBAF for ; Fri, 13 Aug 2010 01:14:26 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMCAJkdZExKfVIqmGdsb2JhbACBRJMJi2AIFQEBAQEBCAkMBxEiokqLIgEFjyMBBIU6 X-IronPort-AV: E=Sophos;i="4.55,360,1278280800"; d="scan'208,217";a="57028372" Received: from mail-ww0-f42.google.com ([74.125.82.42]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Aug 2010 01:14:25 +0200 Received: by wwf26 with SMTP id 26so21767wwf.3 for ; Thu, 12 Aug 2010 16:14:25 -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=YA1BKs9tEuftCpXbCvoG7AdapU4ISZMboBExSWzdXi0=; b=AdTd7HAohsmmzZ+T4SzZkput4CUwwjiQ4CFKjt193XXeAni9fqk3ucoTelDAIq4ucX UXME8d07hF98ufNEYGKxso59yYOWx73a6js2hlqQFe2hFhx5lfg9Hf8RckjD/yYSk1Iy 097aZG+GxdzeZEKX7QBV8vfOHRRVQfdKqnAZE= 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=w3nBfYWrSwg6FeGRIm8XjQ8oXmFnv9awBKAcjA2Z2kT25i1+1gedjhYL9ZntP4or3/ Ra4sHz9+LzpGdOtUjv1vXDcgmG6r8OxJXBoiyfoBCoD8kJS5CxPxAqzP7h1JGs1nOCSj gk7ri+VSj8Teb9plwplj9vDTLBXDW8jmq/8+M= Received: by 10.227.143.12 with SMTP id s12mr705127wbu.125.1281654865558; Thu, 12 Aug 2010 16:14:25 -0700 (PDT) Received: from WinEight ([87.113.155.108]) by mx.google.com with ESMTPS id a1sm1695569wbb.2.2010.08.12.16.14.21 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 16:14:23 -0700 (PDT) From: Jon Harrop To: "'Jeremy Bem'" , "'Jon Harrop'" Cc: "'bluestorm'" , "'caml-list List'" , "'Florian Weimer'" References: <877hk1m1df.fsf@mid.deneb.enyo.de> <87bp9dkkca.fsf@mid.deneb.enyo.de> <4c5f194e.8644d80a.7fef.69e6@mx.google.com>

<03fb01cb3955$76093770$621ba650$@com> In-Reply-To: Subject: RE: [Caml-list] interest in a much simpler, but modern, Caml? Date: Fri, 13 Aug 2010 00:14:19 +0100 Organization: Flying Frog Consultancy Message-ID: <009e01cb3a74$193f5770$4bbe0650$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01CB3A7C.7B03BF70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs5tFhja6ItLvdwTMqDPpU5/IodeAAvmn7A Content-Language: en-gb X-Spam: no; 0.00; bool:01 delimited:01 overloading:01 hashing:01 cheers:01 ocaml's:01 runtime:01 abstraction:01 ocamllex:01 pervasives:01 syntax:01 ocaml:01 overloading:01 minimalist:01 higher-order:01 This is a multi-part message in MIME format. ------=_NextPart_000_009F_01CB3A7C.7B03BF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Presumably, in general, that would need to be: If Bool.(Int.(x=42) || Int.(x=45)) . At which point things start to look hairy. To be honest, I see this delimited overloading as the best of a bad job in the absence of equality types or per-type functionality. I think what we really want is to be able to define custom equality, comparison and hashing on types when structural versions are not applicable. F#'s solution is pretty good. Type classes are a generalization but I do not see that they buy you much for the added complexity. I'd have thought this (at least equality types) would be worth putting in a minimalistic language because it is so useful. Cheers, Jon. From: Jeremy Bem [mailto:jeremy1@gmail.com] Sent: 12 August 2010 01:22 To: Jon Harrop Cc: bluestorm; caml-list List; Florian Weimer Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml? On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop wrote: What happens when you do: if Int.(x = 42 || x = 45) then ... else ... Presumably it either barfs on the assumption that "||" refers to bitwise-or between ints, or we're back to inventing progressively more absurd operator names for each individual combination of types over which they might work. How so? I think this is a borderline case (even in C++, "||" does not refer to bitwise-or). But even if Int.(||) *were* defined as some sort of integer operation, one could simply write: if Int.(x = 42) || Int.(x = 45) Also, I think the discussion has shifted. For me, the local open is a reasonably appealing way to stop using OCaml's exotic polymorphic operators whose behavior depends on the runtime representation and which don't respect type abstraction. (For example, ocamllex uses Pervasives.(=) to test whether Map's are empty, but this breaks if the Map representation changes.) Moreover the syntax even maintains OCaml compatibility thanks to the recent update. But now we seem to be talking about operator overloading, and I'm just not convinced it's necessary at all in a system with a minimalist aesthetic. Back to the local opens, I find that I'm hesitant to add so many of them, especially for equality. Polymorphic equality is hardly unnatural, after all (cf. higher-order logic). I wonder, do any practical languages use quotient types to implement custom equality predicates? In principle, Pervasives.(=) ought to be the "finest" reasonable equivalence relation on a type, which could then be coarsened: type foo = Foo of int | Goo of string let _ = assert (Foo 3 <> Goo "3") (* duh *) let foo_equiv x y = match x, y with Foo a, Foo b -> a=b | Goo a, Goo b -> a=b | Foo a, Goo b | Goo b, Foo a -> string_of_int a = b type goo = foo / foo_equiv (* automatically creates goo_of_foo *) let _ = assert (goo_of_foo (Foo 3) = goo_of_foo (Goo "3")) This would require runtime support. I envision that every "goo" is a block whose tag is "Quotient_tag" and which stores a "foo_equiv" closure in its first Obj field. As it happens, this approach would dovetail with my plans for an integrated proof assistant. Of course it lacks the "conservatism" I've been promoting :) -Jeremy ------=_NextPart_000_009F_01CB3A7C.7B03BF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Presumably, in general, that would need to = be:

If Bool.(Int.(x=3D42) || Int.(x=3D45)) = …

At which point things start to look hairy. To be honest, = I see this delimited overloading as the best of a bad job in the absence of = equality types or per-type functionality. I think what we really want is to be = able to define custom equality, comparison and hashing on types when structural versions are not applicable. F#’s solution is pretty good. Type = classes are a generalization but I do not see that they buy you much for the = added complexity.

I’d have thought this (at least equality types) = would be worth putting in a minimalistic language because it is so = useful.

Cheers,

Jon.

From: Jeremy Bem = [mailto:jeremy1@gmail.com]
Sent: 12 August 2010 01:22
To: Jon Harrop
Cc: bluestorm; caml-list List; Florian Weimer
Subject: Re: [Caml-list] interest in a much simpler, but modern, = Caml?

On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop <jonathandeanharrop@goog= lemail.com> wrote:

What happens when you do:

if Int.(x =3D 42 || x =3D 45) then ... else ...

Presumably it either barfs on the assumption that "||" refers = to bitwise-or
between ints, or we're back to inventing progressively more absurd = operator
names for each individual combination of types over which they might = work.

How so? I think this is a borderline case = (even in C++, "||" does not refer to bitwise-or). But even if = Int.(||) *were* defined as some sort of integer operation, one could simply = write:

if Int.(x =3D 42) || Int.(x =3D = 45)

Also, I think the discussion has shifted. For = me, the local open is a reasonably appealing way to stop using OCaml's exotic polymorphic operators whose behavior depends on the runtime = representation and which don't respect type abstraction. (For example, ocamllex uses Pervasives.(=3D) to test whether Map's are empty, but this breaks if the = Map representation changes.) Moreover the syntax even maintains OCaml compatibility thanks to the recent update. But now we seem to be = talking about operator overloading, and I'm just not convinced it's necessary at = all in a system with a minimalist aesthetic.

Back to the local opens, I find that I'm hesitant = to add so many of them, especially for equality. Polymorphic equality is = hardly unnatural, after all (cf. higher-order logic). I wonder, do any = practical languages use quotient types to implement custom equality predicates? = In principle, Pervasives.(=3D) ought to be the "finest" = reasonable equivalence relation on a type, which could then be = coarsened:

type foo = =3D Foo of int | Goo of string

let _ =3D = assert (Foo 3 <> Goo "3") (* duh *)

let = foo_equiv x y =3D

match x, y with

Foo a, Foo b -> a=3Db

| Goo a, Goo b -> a=3Db

| Foo a, Goo b

| Goo b, Foo a -> string_of_int a =3D b

type goo = =3D foo / foo_equiv (* automatically creates goo_of_foo *)

let _ =3D = assert (goo_of_foo (Foo 3) =3D goo_of_foo (Goo = "3"))

This would require runtime support. I = envision that every "goo" is a block whose tag is "Quotient_tag" = and which stores a "foo_equiv" closure in its first Obj = field.

As it happens, this approach would dovetail with my = plans for an integrated proof assistant. Of course it lacks the "conservatism" I've been promoting :)

-Jeremy

------=_NextPart_000_009F_01CB3A7C.7B03BF70--