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 XAA05378 for caml-red; Fri, 21 Jul 2000 23:21:28 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA21773 for ; Fri, 21 Jul 2000 14:23:26 +0200 (MET DST) Received: from mail.cs.uu.nl (sunset.cs.uu.nl [131.211.80.32]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e6LCNP929741 for ; Fri, 21 Jul 2000 14:23:26 +0200 (MET DST) Received: from silvester.cs.uu.nl.cs.uu.nl (silvester.cs.uu.nl [131.211.80.119]) by mail.cs.uu.nl (Postfix) with ESMTP id 47D644525; Fri, 21 Jul 2000 14:23:25 +0200 (MET DST) From: Frank Atanassow MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14712.16572.925353.202223@silvester.cs.uu.nl> Date: Fri, 21 Jul 2000 14:23:24 +0200 (MET DST) To: Markus Mottl Cc: John Gerard Malecki , OCAML Subject: Re: [newbie] Define and use records in sum types In-Reply-To: <20000719221048.B23676@miss.wu-wien.ac.at> References: <20000717120151.A32148@miss.wu-wien.ac.at> <14709.63462.792269.194367@ish.artisan.com> <20000719221048.B23676@miss.wu-wien.ac.at> X-Mailer: VM 6.75 under Emacs 20.4.1 Sender: weis@pauillac.inria.fr Markus Mottl writes: > On Wed, 19 Jul 2000, John Gerard Malecki wrote: > > type male = { male_name : string; male_salary : int } > > type female = { female_name : string; female_salary : float } > [..] > Well, anyway, modules solve the problem quite well - why not use them? The > effort is hardly worth mentioning. > > E.g.: > > module Male = struct > type t = { name : string; salary : int } > let raise_salary p n = { p with salary = p.salary + n } > end > > module Female = struct > type t = { name : string; salary : float } > let raise_salary p n = { p with salary = p.salary +. n } > end I used to do this. (Actually, in this case I would have used a functor to capture the commonality.) But I stopped because inevitably, after some development, the type t becomes recursive, and you cannot have recursive types spanning modules, so I would have to go back to the straightforward method. > > The idea is to allow the disambiguation to be optional. It may > > confuse novices but ... > > I'd opt against this: to me, modules already provide a regular way to > organize namespaces - no need to add even further constructs to the > language... I disagree. In fact, I think one should divorce the type abstraction and namespace-handling aspects of modules. It's true that the uses often coincide, but I think it obscures the issues. In particular, I think it encourages programmers to conflate syntactic information-hiding (like not exporting some constructors or functions) with type-theoretic information-hiding (like abstracting a type with a functor). The first ought to be considered only as an engineering technique to reduce complexity. The second OTOH is a logical technique to increase flexibility of implementation. As it stands, though, I realize that the current module system is far too entrenched to change, so I would be happy if we could just qualify constructor and field labels by their type constructor's name, so that this would typecheck: type r1 = { name: int } type r2 = { name: float } type t1 = A of int type t2 = A of float let (r2,t2) : r2 * t2 = { name = 1.0 }, A 2.0 let (r1,t1) : r1 * t2 = { r1.name = 1 }, t1.A 2 I believe this issue came up a few months ago... -- Frank Atanassow, Dept. of Computer Science, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-1012, Fax +31 (030) 251-3791