From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 6E749BBAF for ; Mon, 9 Aug 2010 13:55:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4CADaJX0xKfVIukGdsb2JhbACgPAgVAQEBAQkJDAcRAx+nOIkQghGFSS6IVAEBAwWFNQSEJg X-IronPort-AV: E=Sophos;i="4.55,341,1278280800"; d="scan'208";a="67419271" Received: from mail-ww0-f46.google.com ([74.125.82.46]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Aug 2010 13:55:29 +0200 Received: by wwb17 with SMTP id 17so1023287wwb.3 for ; Mon, 09 Aug 2010 04:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject :to:cc:in-reply-to:references:mime-version:content-type:content-id; bh=DhR6IB98cFng/F8XHkH9MK+gxNGbRjsHWcqFDQ5BE64=; b=MLiHpoVhLRBhTeTm0MVH/PDRzK5i027R2AW9LtkfBtPwm5LQ94K47C0Mx5kSLkMlms mDctNZRuZlm+oc7SzoqCxYgT3Ht+VUjks0XJs4oYDOvC9pe73aVF/fB2H3b7ub9Lq1Tz UKOljipK3gWs3rzYWhMEjrASf7/SllVY6GD0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:to:cc:in-reply-to:references :mime-version:content-type:content-id; b=xBhDFdRWex4NysLpPZrmLVFqszcEGRO/s9RQHljgp+1o/IT8DRVvlyMaV9gnN/BN/a rbzxxB0D6xUMVk4Jy9owZQgcIv1q6zgLptxIivMgwUWiTOFOpqP88NxzPk79Ppm+8XzE deANf1cpWydQ0dX4056a02/PkNa6r3dQElyYE= Received: by 10.227.133.142 with SMTP id f14mr13317453wbt.2.1281354928344; Mon, 09 Aug 2010 04:55:28 -0700 (PDT) Received: from localhost (sk.feydakins.org [94.23.4.142]) by mx.google.com with ESMTPS id i25sm4284639wbi.16.2010.08.09.04.55.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 04:55:27 -0700 (PDT) Message-ID: <4c5fecaf.d908e30a.01a0.ffffa6da@mx.google.com> Date: Mon, 09 Aug 2010 04:55:27 -0700 (PDT) From: Nicolas Pouillard Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml? To: Jeremy Bem , Florian Weimer Cc: caml-list List In-Reply-To: References: <877hk1m1df.fsf@mid.deneb.enyo.de> <87bp9dkkca.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23898.1281354926.1@sk.feydakins.org> X-Spam: no; 0.00; ocaml's:01 omitting:01 caml's:01 foo:01 foo:01 hashing:01 marshalling:01 hash:01 marshalling:01 variants:01 hashing:01 literals:01 mutable:01 clases:98 sml:01 On Sun, 8 Aug 2010 15:39:28 -0400, Jeremy Bem wrote: > 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. As said in my previous email local opening can help here: if Char.('A' <= c && c <= 'Z') then ... > 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. Having to recode them sure is tedious but very simple as well in these case: match myfoo with Foo 3 -> ... | ... > 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. With type clases you would have a class for each of them. For sure it make sense to keep them all like you keep the Obj module the difference is the intended usage if they are called Unsafe_generic_equality.(=), unsafe_generic_hash, and unsafe_generic_marshalling then its fine. For sure we then want to expose safer variants of those to the user. Another idea that can help would be to have only one builtin type class (no not the equality one as in SML), the Typeable class. This class simply expose a value to represent a type. In these three cases (equality, marshalling, and hashing) we will even don't look at these values, the purpose is to give us the right to behave in a non-parametric way. However it does not fix the equality for abstract types, so I don't know if the gain worth the added complexity. > 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. For sure it would a lot nicer to have at least a type for immutable strings and make the literals immutable. Then having a second type for mutable strings and two copying functions (freeze and thaw) to convert them would help you a lot in adapting existing code. Regards, -- Nicolas Pouillard http://nicolaspouillard.fr