From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: patrick@watson.org
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Date: Tue, 03 Apr 2001 18:30:50 +0900 [thread overview]
Message-ID: <20010403183050B.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <Pine.BSF.3.96.1010403002221.97906B-100000@fledge.watson.org>
Hi Patrick,
This is only a point by point answer.
On labels vs. extensible records:
> > I'm not really convinced of that. SML for instance has structural
> > records, and uses them in its basis library. You can look at the result
> > for yourself. For me it's only half the way.
[...]
> I think that we're in agreement here. Structural records like SML is a
> start, but light-weight extensible records would address most of these
> issues.
>
> - Labeled arguments are included in a record, and unlabelled arguments
> are outside of the record. And since they are light-weight, there is no
> need to declare a type definition for the record.
That's exactly what I was pointing as a weaker form of commutation:
labeled arguments commute between themselves, but they do not commute
with non-labeled arguments.
> - Labels and currying do give a nicer syntax. On the other hand, not
> having good support for records is a detriment to the syntax. Most
> programmers coming to Caml will have an expectation that fields can belong
> to more than one record. Luckily, labelled arguments removes at least one
> reason for light-weight records.
I know the lack of light-weight records is a pain, but we have already
two record-like structures in OCaml, and tuples. Predefined records
have their advantages, so this would mean adding yet another
structure. This may happen someday, but I'm not all that
enthusiastic.
> - Optional arguments can be addressed by having a value which
> contains the default arguments which is modified by a record update
> syntax.
This handles only default arguments, optional arguments are more
powerful since their value may be computed at call time.
On proper labellings:
> > I have also eta-expanded more than necessary, to make the code more
> > readable.
> > We can write something shorter if we use labels as they were in ocaml
> > 2.99, before their trimming:
> > List.fold_left lists ~acc:IntSet.empty
> > ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
> > Now, which is the more readable program, this one or yours.
>
> Hmm... hard to say. Using this API, I would wonder why isn't there a label
> for the list? It would be much simpler if every argument to a function had
> to have a label. I know this presents its own problems, but it adds to
> the things one must remember for coding.
I think this is explained in the tutorial: you should not label the
object of the operation. Normally one learns that in elementary
school, but forgets it soon after, so it can be a bit difficult.
Requires some practice before it comes out naturally.
> Regarding Haskell, what you say is surprising since I would classify
> a common use of monadic binding as a folding function. For the operator
> (>>=) which has type
>
> (>>=) :: m a -> (a -> m b) -> m b
>
> if a and b are the same type than it is a folding over computation state.
> This is certainly a common use in real programs.
I was only talking of list folding functions.
Labels are not the only way to improve readability. Infix operators
can also help.
On type errors in label mode:
> Forgetting to use the label in commuting mode can lead to incredible
> cryptic error messages.
The situation has improved a bit with 3.01.
Give it a try to see the difference. This is not perfect yet, but if
you see something clearly wrong you can send a bug report.
> As discussed above, I like to use a variant of
> list folding that gets the arugments in the "right" order and is
> tail-recursive. I tried adding labels to the arguments to see what would
> happen when they were omitted. The result was pretty surprising:
>
> val listFold : f:('a -> 'b -> 'b) -> l:'a list -> acc:'b -> 'b
>
> let cons x l = x :: l
>
> listFold cons (listFold cons [5;4;3] []) [];;
>
> While this is a contrived example to reverse a list twice, not including
> the labels gave this impressive type back from the compiler:
[monstruous type]
This problem is specific to functions returning a polymorphic type:
if your arguments match none of the labels in the function type, they
will be seen as arguments to the result of the function, producing a
huge type by unification.
If you had tried on an instanciated typed, you would have got a more
reasonable answer.
# let rec listFold ~f ~l ~(acc : int) =
match l with [] -> acc
| x :: l -> listFold ~f ~l ~acc:(f x acc);;
val listFold : f:('a -> int -> int) -> l:'a list -> acc:int -> int = <fun>
# let cons x l = x :: l;;
val cons : 'a -> 'a list -> 'a list = <fun>
# listFold cons (listFold cons [5;4;3] []) [];;
Expecting function has type
f:('a -> int -> int) -> l:'a list -> acc:int -> int
This argument cannot be applied without label
When there is enough information, one can produce accurate error
messages.
> I think this is more than enough to frighten me from using commuting label
> mode. The classic mode seems to give more sensible error messages.
In practice, I do not bump into this kind of errors very often.
In real programs, functions returning a polymorphic variable as result
are not so frequent.
> Another language that I'm very familiar with that has labelled arguments
> (in some sense) is Verilog. Instantiation by named connection is
> really crucial to using the language safely. Some observations though:
>
> 1) There are no structures in the language, so some need of labelling is
> needed.
Indeed, you will fell more directly need for labels in dynamically
typed languages.
But, while this may be true that labels are less needed from the
point-of-view of type safety, for documentation the need is identical.
Particularly in ML you don't write type annotations, and it is often
hard to follow the role of a variable in a program. Ocamlbrowser can
give you this information, but this does not replace information about
the role of an argument, which appears to be most needed when reading
a program.
> 2) There is no partial application which makes it easier to give
> intelligent error messages.
But partial application makes commutation more interesting :-)
Thanks for all these good points.
Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-04-03 9:28 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-31 3:40 [Caml-list] Future of labels Yaron M. Minsky
2001-04-02 3:39 ` [Caml-list] Future of labels, and ideas for library labelling Jacques Garrigue
2001-04-02 7:58 ` Judicael Courant
2001-04-02 8:50 ` Markus Mottl
2001-04-02 10:33 ` kahl
2001-04-03 0:35 ` Jacques Garrigue
2001-04-03 1:36 ` Kipton M Barros
2001-04-03 1:52 ` Patrick M Doane
2001-04-03 3:53 ` Jacques Garrigue
2001-04-03 5:10 ` Patrick M Doane
2001-04-03 9:30 ` Jacques Garrigue [this message]
2001-04-03 8:52 ` Xavier Leroy
2001-04-03 9:34 ` Judicael Courant
2001-04-03 9:54 ` Jacques Garrigue
2001-04-03 12:59 ` Jean-Christophe Filliatre
2001-04-03 13:11 ` [Caml-list] ocaml, java, rmi and jini Martin Berger
2001-04-03 19:23 ` Chris Hecker
2001-04-03 20:50 ` Gerd Stolpmann
2001-04-06 9:40 ` Sven LUTHER
2001-04-06 20:57 ` Gerd Stolpmann
2001-04-03 21:06 ` martinb
2001-04-06 15:03 ` Xavier Leroy
2001-04-03 14:06 ` [Caml-list] Future of labels, and ideas for library labelling Jacques Garrigue
2001-04-03 14:12 ` Daniel de Rauglaudre
2001-04-03 14:42 ` Claude Marche
2001-04-04 19:18 ` Gerd Stolpmann
2001-04-03 9:55 ` Ohad Rodeh
2001-04-03 18:06 ` [Caml-list] Example of Ocaml-syntax problem with ; Mattias Waldau
2001-04-04 15:15 ` [Caml-list] Suspending threads Ohad Rodeh
2001-04-04 17:28 ` Vitaly Lugovsky
2001-04-06 13:21 ` Xavier Leroy
2001-04-03 12:02 ` [Caml-list] Future of labels, and ideas for library labelling Dave Mason
2001-04-03 13:43 ` Francois-Rene Rideau
2001-04-03 14:23 ` Daniel de Rauglaudre
2001-04-03 13:43 ` Frank Atanassow
2001-04-03 13:58 ` Joshua D. Guttman
2001-04-03 16:52 ` Eric C. Cooper
2001-04-09 9:05 ` John Max Skaller
2001-04-09 7:29 ` John Max Skaller
2001-04-03 8:07 ` Judicael Courant
2001-04-03 6:55 ` Chris Hecker
2001-04-03 18:13 ` [Caml-list] Generics? Brian Rogoff
2001-04-03 20:12 ` Chris Hecker
2001-04-10 16:48 ` John Max Skaller
2001-04-09 8:11 ` [Caml-list] Future of labels, and ideas for library labelling John Max Skaller
2001-04-09 9:21 ` Jacques Garrigue
2001-04-09 15:06 ` Fergus Henderson
2001-04-10 18:49 ` John Max Skaller
2001-04-09 19:54 ` Chris Hecker
2001-04-10 3:37 ` Jacques Garrigue
2001-04-10 7:42 ` Judicael Courant
2001-04-10 8:25 ` Jacques Garrigue
2001-04-10 8:46 ` Claude Marche
2001-04-10 10:09 ` Jacques Garrigue
2001-04-10 14:42 ` Lionnel Maugis
2001-04-10 9:06 ` François-René Rideau
2001-04-11 15:34 ` Jacques Garrigue
2001-04-11 17:48 ` Dave Mason
2001-04-12 12:39 ` [Caml-list] How do I define prog1? Mattias Waldau
2001-04-12 14:22 ` Vitaly Lugovsky
2001-04-12 17:53 ` William Chesters
2001-04-12 15:15 ` Sven LUTHER
2001-04-12 16:14 ` Mattias Waldau
2001-04-12 15:21 ` Maxence Guesdon
2001-04-12 15:47 ` Stefan Monnier
2001-04-17 20:04 ` Chris Hecker
2001-04-10 22:43 ` [Caml-list] Future of labels, and ideas for library labelling Brian Rogoff
2001-04-11 8:29 ` Jacques Garrigue
2001-04-11 9:44 ` Anton Moscal
2001-04-11 13:16 ` Didier Remy
2001-04-11 15:11 ` Jacques Garrigue
2001-04-03 7:27 Arturo Borquez
2001-04-03 16:39 John R Harrison
2001-04-04 16:37 Dave Berry
2001-04-11 10:48 Francois-Rene Rideau
2001-04-17 11:53 Poigné
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=20010403183050B.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=patrick@watson.org \
/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;
as well as URLs for NNTP newsgroup(s).