From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA13456 for caml-red; Thu, 14 Dec 2000 19:23:14 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA03657 for ; Wed, 13 Dec 2000 14:14:02 +0100 (MET) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id eBDDE1L03095 for ; Wed, 13 Dec 2000 14:14:02 +0100 (MET) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_0045_3a37_7657_59cb; Wed, 13 Dec 2000 13:15:03 +0000 Received: from somewhere by smtpxd Message-ID: <3145774E67D8D111BE6E00C0DF418B6638D1C9@nt.kal.com> From: Dave Berry To: Chris Hecker , Mattias Waldau , Caml-List Subject: RE: Same label in different types, how do people solve this? Date: Wed, 13 Dec 2000 13:17:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr The same issue arises with variant types -- a constructor defined in one type cannot be defined in a later type. Do you find this to be a problem as well? One could make an argument that languages should be consistent in how they treat these two cases. OCaml was consistent until it added polymorphic variants. SML is not consistent, because it forbids redefinition of constructors but permits fields to be used in different record types. (Technically, SML record types are types in their own right, unlike CAML record types which must be named). Also, I'm curious as to why the module approach doesn't meet your requirements. Do you really need to use different types with the same label in the same module? Dave. -----Original Message----- From: Chris Hecker [mailto:checker@d6.com] Sent: Monday, December 11, 2000 18:24 To: Mattias Waldau; Caml-List Subject: RE: Same label in different types, how do people solve this? >I understand that all you functional experts thinks this restriction is >obvious, but for me it is more like a bug/misfeature. So this 'misfeature' >should actually be stated for all us who aren't interested how types are >infered in functional programming. I'm with Mattias on this one. I'm practical above theoretical. All of the workarounds for this problem seem like they generate way more tedious work for the programmer, and they still don't quite accomplish the goal 100%. This characteristic of doing more work and only asymptotically approaching your goal is a bad taste I associate with C++. Anyway, my "vote" would be to allow specification, with : if it's possible since it's the obvious syntax, but even with @@ if necessary (even though I think it's really ugly). Chris