Browse thread
[newbie] Define and use records in sum types
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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