From: Frank Atanassow <franka@cs.uu.nl>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: John Gerard Malecki <johnm@artisan.com>, OCAML <caml-list@inria.fr>
Subject: Re: [newbie] Define and use records in sum types
Date: Fri, 21 Jul 2000 14:23:24 +0200 (MET DST) [thread overview]
Message-ID: <14712.16572.925353.202223@silvester.cs.uu.nl> (raw)
In-Reply-To: <20000719221048.B23676@miss.wu-wien.ac.at>
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
next prev parent reply other threads:[~2000-07-21 21:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-11 11:32 David Mentré
2000-07-17 10:01 ` Markus Mottl
[not found] ` <14709.63462.792269.194367@ish.artisan.com>
2000-07-19 20:10 ` Markus Mottl
2000-07-21 12:23 ` Frank Atanassow [this message]
2000-07-21 20:00 ` Markus Mottl
2000-07-22 13:34 ` Frank Atanassow
2000-07-22 18:31 ` Markus Mottl
2000-07-23 13:55 ` Frank Atanassow
2000-07-23 15:20 ` Markus Mottl
2000-07-24 9:28 ` Frank Atanassow
2000-07-25 5:26 ` Alan Schmitt
2000-07-19 19:21 ` Jean-Christophe Filliatre
2000-07-20 7:08 ` David Mentré
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14712.16572.925353.202223@silvester.cs.uu.nl \
--to=franka@cs.uu.nl \
--cc=caml-list@inria.fr \
--cc=johnm@artisan.com \
--cc=mottl@miss.wu-wien.ac.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox