Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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



  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