From: Pierre Weis <Pierre.Weis@inria.fr>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
Date: Wed, 15 Mar 2000 14:58:30 +0100 [thread overview]
Message-ID: <20000315145830.22463@pauillac.inria.fr> (raw)
In-Reply-To: <20000315121549A.garrigue@kurims.kyoto-u.ac.jp>; from Jacques Garrigue on Wed, Mar 15, 2000 at 12:15:49PM +0900
[Sorry, no french version for this long message]
Abstract:
A long answer to Jacques's proposal. I do not discuss syntax but
semantic issues of the label extension. My conclusion is to be very
careful in adding labels into the standard libraries, and also state
as a extremely desirable design guideline to keep the usage of higher
order functions as simple as possible.
> *** Proposal
>
> Objective Caml 3.00 is not yet released, and I believe we can still
> have modifications on this point.
Yes, you're perfectly right, we can still modify several points.
However, I think there are many other points that are more important
than the choice of ``%'' instead of ``:'', which is only cosmetic
after all.
Thus, I would prefer to discuss deeper and more semantic problems:
-- Problem1: labels can be reserved keywords. This is questionable
and it has been strongly criticised by some Caml users, especially when
reading in the code the awful sequence fun:begin fun ...
-- Problem2: labels that spread all over the standard libraries, even
when they do not add any good. I would cite:
* the labels completely redundant with the types
(E.g. char:char in the type of String.contains or String.index)
* undesired labels: in many cases I don't want to have labels just
because I don't want to remember their names. (E.g., I very often
mispell the label acc since I've always used accu to name an
accumulator; furthermore, when I do not mispell this label, I feel
acc:accu extremely verbose). Also because labels are verbose at
application.
* labels that prevent you to use comfortably your traditional functions.
This is particularly evident for the List.map or List.fold_right
higher-order functionals.
This last point is a real problem. Compare the usual way of using
functionals to define the sum of the elements of a list:
$ ocaml
Objective Caml version 2.99+10
# let sum l = List.fold_right ( + ) l 0;;
val sum : int list -> int = <fun>
Clearly application is denoted in ML with only one character: a space.
Now, consider using the so-called ``Modern'' versions of these
functionals, obtained with the -modern option of the compiler:
$ ocamlpedantic
Objective Caml version 2.99+10
# let sum l = List.fold_right ( + ) l 0;;
^^^^^
This expression has type int -> int -> int but is here used with type 'a list
Clearly, there is something wrong now! We may remark that the error
message is not that clear, but this is a minor point, since error
messages are never clear enough anyway!
The real problem is that fixing the code makes no good at all to its
readability (at least that's what I would say):
# let sum l = List.fold_right fun:begin fun x acc:y -> x + y end acc:0;;
val sum : 'a -> int list -> int = <fun>
It seems that, in the ``modern'' mode, application of higher order
functions is now denoted by a new kind of parens opening by
``fun:begin fun'' and ending by ``end''. This is extremely explicit
but also a bit heavy (in my mind).
For all these reasons, I would suggest to carefully use labels into
the standard libraries:
-- remove labels from higher-order functional
-- remove redundant labels: when no ambiguity can occur you need not
to add a label.
-- use labels when typechecking ambiguity is evident (for instance
when there are two or more parameters with the same type).
Labels must enforce readability of code or help documenting the
libraries, it should not be an extra burden to the programmer and a
way of offuscating code.
Evidently, as any other extension, labels must not offuscate the
overall picture, that is they must not clobber the semantics, nor add
extra exceptional cases to the few general rules we have for the
syntax and semantics of Caml.
In this respect, optional labelled arguments might also be discussed,
particularly for the following facts:
-- syntactically identical patterns and expressions now may have
incompatible types:
# let f ?style:x _ = x;;
val f : ?style:'a -> 'b -> 'a option = <fun>
As a pattern on the left-hand side x has type 'a, while as an
expression on the right hand side it has type 'a option
-- some expressions can be only written as arguments in an application
context:
# let f ?style:x g = ?style:x;;
^
Syntax error
# let f ?style:x g = g ?style:x;;
val f : ?style:'a -> (?style:'a -> 'b) -> 'b = <fun>
-- the simple addition of a default value to an optional argument may
trigger a typechecking error:
# let f ?(style:x) g = g ?style:x;;
val f : ?style:'a -> (?style:'a -> 'b) -> 'b = <fun>
# let f ?(style:x = 1) g = g ?style:x;;
This expression has type int but is here used with type 'a option
Do not forget the design decision that has always been used before in
the development of Caml: interesting but not universal extensions to
the language must carefully be kept orthogonal to the core language
and its libraries. This has been successfully achieved for the
important addition of modules (that do not prevent the users from
using the old interface-implementation view of modules) as well as for
the objects system addition that has been also maintained orthogonal
to the rest of the language (in particular the standard library has
never been ``objectified''). I don't know of any reason why labels
cannot follow the same safe guidelines.
> Here is an alternative proposal, to use `%' in place of `:'. Labels
> are kept as a lexical entity. This still breaks some programs, since
> `%' was registered as infix, but this is not so bad.
> Con:
> * I still think that `:' looks better, particularly inside types.
> * On my keyboard I can type in `:' without pressing shift :-)
> * We will need some tool to convert existing code.
I think that % should be the infix integer modulo symbol.
> Do you think it would be better?
No.
> Are there people around who would rather keep `:' ?
Yes. However this is syntax and we have to consider semantics in the
first place.
There are also people around that would like to keep Caml a true
functional language, where usage of higer order functions is easy and
natural. We have to be careful not to lose what is the actual
strength of the language.
--
Pierre Weis
INRIA, Projet Cristal, http://pauillac.inria.fr/~weis
next prev parent reply other threads:[~2000-03-15 14:09 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-14 16:53 Syntax for label Don Syme
2000-03-14 18:05 ` Pierre Weis
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 [this message]
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-18 10:32 ` Syntax for label, NEW SOLUTION Christophe Raffalli
2000-03-19 2:29 ` Jacques Garrigue
2000-03-20 18:25 ` Christophe Raffalli
2000-03-22 8:37 ` Claudio Sacerdoti Coen
2000-03-21 23:29 ` John Max Skaller
2000-03-29 8:42 ` Semantic of label: The best (only ?) solution to merge both mode Christophe Raffalli
2000-03-29 9:53 ` Christophe Raffalli
2000-03-30 9:49 ` John Max Skaller
2000-03-30 9:39 ` John Max Skaller
2000-03-31 4:34 ` Jacques Garrigue
2000-04-01 1:53 ` John Max Skaller
2000-04-02 19:24 ` Christophe Raffalli
2000-04-04 5:50 ` Jacques Garrigue
2000-04-03 7:57 ` backward compatibility Christophe Raffalli
2000-03-15 21:30 ` Syntax for label, NEW PROPOSAL 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-24 9:54 ` labels & ocaml 3 & co David Mentré
2000-03-24 12:19 ` David Mentré
2000-03-21 22:22 ` Unsigned integers? John Max Skaller
2000-03-22 16:22 ` Sven LUTHER
2000-03-23 2:08 ` Max Skaller
2000-03-23 7:50 ` Sven LUTHER
2000-03-24 2:50 ` Jacques Garrigue
2000-03-24 15:59 ` Xavier Leroy
2000-03-25 4:03 ` John Max Skaller
2000-03-24 14:50 ` Xavier Leroy
2000-03-22 17:05 ` Jean-Christophe Filliatre
2000-03-22 19:10 ` Markus Mottl
2000-03-23 2:41 ` Max Skaller
2000-03-22 19:47 ` Xavier Leroy
2000-03-23 12:55 ` John Max Skaller
2000-03-16 8:50 ` Syntax for label, NEW PROPOSAL Pascal Brisset
2000-03-17 11:15 ` Sven LUTHER
2000-03-18 0:04 ` Syntax for label, ANOTHER " Steven Thomson
2000-03-15 20:39 ` Syntax for label (and more) Xavier Leroy
2000-03-17 10:03 ` Christian RINDERKNECHT
2000-03-17 17:19 ` Christophe Raffalli
2000-03-21 1:29 ` Markus Mottl
2000-03-15 20:40 Syntax for label, NEW PROPOSAL 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-17 17:03 Don Syme
2000-03-17 19:24 ` John Prevost
2000-03-17 21:33 Damien Doligez
2000-03-18 21:07 ` Frank Atanassow
2000-03-18 22:40 ` John Prevost
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=20000315145830.22463@pauillac.inria.fr \
--to=pierre.weis@inria.fr \
--cc=caml-list@inria.fr \
--cc=garrigue@kurims.kyoto-u.ac.jp \
/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