Version française
Home     About     Download     Resources     Contact us    
Browse thread
[newbie] Define and use records in sum types
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Frank Atanassow <franka@c...>
Subject: Re: [newbie] Define and use records in sum types
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