From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E3053BBAF for ; Sun, 8 Aug 2010 21:39:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0CAHekXkzRVdY0kGdsb2JhbACfZlYIFQEBAQEJCQwHEQMfpm6JEIIRhQouiFQBAQMFhTUEiTs X-IronPort-AV: E=Sophos;i="4.55,338,1278280800"; d="scan'208";a="65165539" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Aug 2010 21:39:29 +0200 Received: by bwz17 with SMTP id 17so1049813bwz.39 for ; Sun, 08 Aug 2010 12:39:29 -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=HROEuIn5yRNp9OoPaXvnouHnB7A6GH5lC8/NuJdqS/A=; b=Mz9G+IUbcCVVebVkpjUBfZkg/4K7Ke3SveLF2oshEpjq6QbLodHwg1yq7j4OfIxFeb uHLYFh1zsGon94MZlXam/YqJ1yAvGUG63RkIgZehIJEID8MiElunCNTN5Pdhe4Ao9C0V vqS1Yul5vj2WRjqtMczQnx+hMDgOyJ7kfGvRA= 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=aUKeUJOVIxPAK5qTQ1udIUcOnFz3RQS/lnQigojOnaGNLwiVsg+0rgeBPzhkXHHHVy npOi9RAw3SOaA0Gn8KCkQ2eb0tmIDVl1SsaV48sH0KIIgpOSmMtSzRSRoWM5+AkEVkpA bhY1kKfncaQyl3cMEhC+PnR6kxW2I6vo8csXQ= MIME-Version: 1.0 Received: by 10.204.19.83 with SMTP id z19mr2270358bka.43.1281296369035; Sun, 08 Aug 2010 12:39:29 -0700 (PDT) Received: by 10.204.54.68 with HTTP; Sun, 8 Aug 2010 12:39:28 -0700 (PDT) In-Reply-To: <87bp9dkkca.fsf@mid.deneb.enyo.de> References: <877hk1m1df.fsf@mid.deneb.enyo.de> <87bp9dkkca.fsf@mid.deneb.enyo.de> Date: Sun, 8 Aug 2010 15:39:28 -0400 Message-ID: Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml? From: Jeremy Bem To: Florian Weimer Cc: caml-list List Content-Type: multipart/alternative; boundary=00032555a3daedab7d048d550e19 X-Spam: no; 0.00; ocaml's:01 omitting:01 caml's:01 lexer:01 syntax:01 variants:01 syntax:01 ocaml:01 foo:01 foo:01 hashing:01 marshalling:01 ocaml's:01 omitting:01 caml's:01 --00032555a3daedab7d048d550e19 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer wrote: > * Jeremy Bem: > > > Yes and no, respectively. In other words, nothing new here. > > Oh. I just happen to think that those two are very high on the list > of things you want to fix once you can start with a clean slate. > > > Is there a better approach to polymorphic equality floating around? > > Besides type classes? I'm not sure. It's probably possible to remove > this feature from the language, with a little bit of syntactic > overhead to pass around a matching comparison function. > Maybe I should clarify that my main goal has been to bring Caml Light up-to-date with OCaml's improvements, while keeping the type-checking code very simple, not to try to make further improvements. In fact, I wouldn't necessarily claim that omitting the module and object systems is an improvement, just that it is a simplification. But actually, now that you mention it, I did briefly explore the idea of removing Caml's polymorphic comparison functions. One issue I ran into was syntactic. How would you write: if 'A' <= c && c <= 'Z' then ... where c is a char, without polymorphic comparison, and without more radical changes such as type classes? Ideally the solution would generalize to int64s, etc. I briefly had lexer support for a syntax along the lines of if 'A' <=`c` c && c <=`c` 'Z' then ... In general, the backquote is available since I don't support variants. However, this syntax didn't feel elegant enough to warrant expanding the Llama project's more conservative scope. Currently OCaml can compile Llama code, a feature which doesn't seem like it should be discarded too lightly. I also found multiple instances of a pattern like type foo = Foo of int | Goo of string if myfoo = Foo 3 then ... It felt tedious and perhaps destructive to re-code all of these. Finally, on what theoretical basis do we disallow polymorphic comparison but retain polymorphic hashing and marshalling? Perhaps we just want all these functions to be less convenient, e.g. isolated in their own "Polymorphic" module. After all, Llama retains even the "Obj" module. Once the current system is posted, I could consider making these changes after all. Suggestions to smooth the syntax are more than welcome. Perhaps a bit more time to re-code things carefully is all that is really needed. If there is a broad consensus for immutable strings, I could make that change as well, again with a bit of delay as I'll need to port things like the relocation mechanism in the Llama linker, in order to remain self-hosting. Thanks, Jeremy --00032555a3daedab7d048d550e19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 8, 2010 at 2:52 PM, Florian Weimer <= span dir=3D"ltr"><fw@deneb.enyo.de> wrote:
* Jeremy Bem:

> Yes and no, respectively. =A0In other words, nothing new here.

Oh. =A0I just happen to think that those two are very high on the lis= t
of things you want to fix once you can start with a clean slate.

> Is there a better approach to polymorphic equality floating around?
Besides type classes? =A0I'm not sure. =A0It's probably possi= ble to remove
this feature from the language, with a little bit of syntactic
overhead to pass around a matching comparison function.



=A0=A0if 'A' <=3D c && c <=3D 'Z' then .= ..
where c is a char, without polymorphic comparison, and without= more radical changes such as type classes? =A0Ideally the solution would g= eneralize to int64s, etc.

I briefly had lexer support for a syntax along the line= s of
=A0=A0if 'A' <=3D`c` c && c <=3D`c` &#= 39;Z' then ...
In general, the backquote is available since I= don't support variants. =A0However, this syntax didn't feel elegan= t enough to warrant expanding the Llama project's more conservative sco= pe. =A0Currently OCaml can compile Llama code, a feature which doesn't = seem like it should be discarded too lightly.

I also found multiple instances of a pattern like
=
=A0=A0type foo =3D Foo of int | Goo of string
=A0=A0if myfoo= =3D Foo 3 then ...
It felt tedious and perhaps destructive to re= -code all of these.

Finally, on what theoretical basis do we disallow polym= orphic comparison but retain polymorphic hashing and marshalling? Perhaps w= e just want all these functions to be less convenient, e.g. isolated in the= ir own "Polymorphic" module. =A0After all, Llama retains even the= "Obj" module.

Once the current system is posted, I could consider mak= ing these changes after all. =A0Suggestions to smooth the syntax are more t= han welcome. =A0Perhaps a bit more time to re-code things carefully is all = that is really needed.

If there is a broad consensus for immutable strings, I = could make that change as well, again with a bit of delay as I'll need = to port things like the relocation mechanism in the Llama linker, in order = to remain self-hosting.

Thanks,
Jeremy

--00032555a3daedab7d048d550e19--