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 XAA14705 for caml-red; Fri, 21 Jul 2000 23:25:31 +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 WAA14174 for ; Fri, 21 Jul 2000 22:01:24 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e6LK1N908435 for ; Fri, 21 Jul 2000 22:01:23 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id WAA31126; Fri, 21 Jul 2000 22:00:58 +0200 (MET DST) Date: Fri, 21 Jul 2000 22:00:58 +0200 From: Markus Mottl To: Frank Atanassow Cc: John Gerard Malecki , OCAML Subject: Re: [newbie] Define and use records in sum types Message-ID: <20000721220058.A29053@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> <14712.16572.925353.202223@silvester.cs.uu.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14712.16572.925353.202223@silvester.cs.uu.nl>; from franka@cs.uu.nl on Fri, Jul 21, 2000 at 14:23:24 +0200 Sender: weis@pauillac.inria.fr On Fri, 21 Jul 2000, Frank Atanassow wrote: > Markus Mottl writes: > > 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.) Well, there is not so much commonality to catch in the upper example: to me, a functor would be a bit overkill here if the only thing you want to do is having a separate namespace. Unless you really see a longterm benefit in some abstraction, it's not a good idea to make the code more complex with functors. > 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. Inevitably? Why? At least in the cases where I found a problem with building modules, I always discovered an easy (and generally much cleaner) way to restructure the design to get around it. In fact, such problems point me to design errors. (Yes, there are rare examples, where redesigning does not help, but I never felt the need to implement one for real purposes). > I disagree. In fact, I think one should divorce the type abstraction and > namespace-handling aspects of modules. I agree. > 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. But how about "capturing logical invariants"? You need both ways of information hiding there: restricting the number of exported functions *and* restricting their types! Otherwise there could be ways to destroy the invariant. > 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'd rather use different namings like "r1_name" and "r2_name" for the field: although this requires me to always include the name of the type, one cannot get confused either: it makes the sources easier to understand. Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl