Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Frank Atanassow <franka@cs.uu.nl>
To: Damien Doligez <Damien.Doligez@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
Date: Sat, 18 Mar 2000 22:07:33 +0100 (MET)	[thread overview]
Message-ID: <14547.61461.983342.507068@silvester.cs.uu.nl> (raw)
In-Reply-To: <200003172133.WAA16479@tobago.inria.fr>

Damien Doligez writes:
 > I agree, and I would even go further.  I think the current labeling of
 > the standard library is way too verbose.  "fun" should not be "func"
 > or even "fn", but simply "f".  That's the usual name for a generic
 > function.  Likewise, we should replace char:char with c:char and so
 > on (maybe even the predicate function in List.for_all should be
 > labeled f).

If you hold that the point of labels is to provide extra "type checking", then
naming labels according to the type they annotate is exactly the wrong way to
proceed. For example, if you have a function f : char -> char -> t, you would
want to disambiguate the role of the two characters, since the type checker
cannot catch it, but using the generic label name 'c' will not help you here.

By that token, a convention for picking label names should distinguish
arguments according to their "role" (some semantics above and beyond what can
be expressed with the type system), not their type.

BTW, this thought just occurred to me regarding semantics: you might view
labels as a class of unary type constructors which are the identity on
types. This implies you would write:

  val pow : int Base -> int Exp -> int

The capitalization distinguishes these "identity" constructors from abstract
and primitive ones.

To define pow, you restrict the argument patterns explicitly:

  let pow (b:'a Base) (e:'a Exp) = ...

To use pow, we can either restrict the argument types explicitly:

  pow (2:'a Base) (3:'a Exp)

or rely on type inference. Of course, this doesn't address the issue of
reordering (IMHO the idea of reordering is a little dubious, esp. considering
the interaction with side-effects) and having to insert the type variables is
ugly, but at least it provides some documentation and a less ad hoc approach
to the syntax. Anyway, it's only the germ of an idea.

Another idea is to stipulate a class of kinds (in the sense of "type of a
type") of labels, and distinguish the syntax for kind restriction of values,
say term :: kind (bad choice, I know) from the syntax for type restriction for
values, term : type. However, kind restriction of types is still written
":". Then you write something like:

  val pow : int : base -> int : exp -> int
  let pow (b :: base) (e :: exp) = ..
  pow (b :: base) (e :: exp)

Also you must demand that every label kind is a subkind of the kind Type so
that, for example, (->) can operate on labelled types.

Does this make sense? I'm a little too tired to think very clearly... One
thing I don't like about this is that the label names don't get declared
anywhere, they just seem spring into existence. I guess you could insist that
they get declared somewhere with a new syntactic construct, but I don't see
much point in it.

-- 
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-03-21 14:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-17 21:33 Damien Doligez
2000-03-18 21:07 ` Frank Atanassow [this message]
2000-03-18 22:40 ` John Prevost
  -- strict thread matches above, loose matches on Subject: below --
2000-03-17 17:03 Don Syme
2000-03-17 19:24 ` John Prevost
2000-03-15 20:40 Don Syme
2000-03-17  9:48 ` Jacques Garrigue
2000-03-17 17:34   ` Dave Mason
2000-03-18  0:26     ` Jacques Garrigue
2000-03-23 13:07       ` Sven LUTHER
2000-03-14 16:53 Syntax for label Don Syme
2000-03-15  3:15 ` Syntax for label, NEW PROPOSAL Jacques Garrigue
2000-03-15  6:58   ` Christophe Raffalli
2000-03-15 21:54     ` Julian Assange
2000-03-15 11:56   ` Wolfram Kahl
2000-03-15 13:58   ` Pierre Weis
2000-03-15 15:26     ` Sven LUTHER
2000-03-17  7:44       ` Pierre Weis
2000-03-15 17:04     ` John Prevost
2000-03-17 10:11       ` Jacques Garrigue
2000-03-15 17:06     ` Markus Mottl
2000-03-15 19:11     ` Remi VANICAT
2000-03-17  8:30       ` Pierre Weis
2000-03-17 14:05         ` Jacques Garrigue
2000-03-17 16:08           ` Pierre Weis
2000-03-15 21:30     ` John Max Skaller
2000-03-16  2:55     ` Jacques Garrigue
2000-03-17 15:13       ` Pierre Weis
2000-03-17 17:33         ` Wolfram Kahl
2000-03-18 11:59         ` Jacques Garrigue
2000-03-21 16:51       ` Pascal Brisset
2000-03-23 11:14         ` Nicolas barnier
2000-03-16  8:50     ` Pascal Brisset
2000-03-17 11:15       ` Sven LUTHER

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=14547.61461.983342.507068@silvester.cs.uu.nl \
    --to=franka@cs.uu.nl \
    --cc=Damien.Doligez@inria.fr \
    --cc=caml-list@inria.fr \
    /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