English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] Future of labels, and ideas for library labelling
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-04 (16:39)
From: Dave Berry <Dave@k...>
Subject: RE: [Caml-list] Future of labels, and ideas for library labelling
> -----Original Message-----
> From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp]
> ...
> 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.
> * You cannot mix labeled and unlabeled arguments, whereas you often
>   want to keep one unlabeled argument in your function.

As you say, this is a matter of taste, but I don't agree with your
sentiment here.  I would prefer all labels or none, rather than having
to remember which arguments have labels and which don't.

Better still is the suggestion of Arturo Borquez and Dave Mason, where
labels can be given or not, as the caller pleases.  My only reservation
is that I don't know how easy this would be to extend to optional

> * I believe labels + currying give a nicer syntax.

It's a matter of taste again, but I think the OCaml label syntax is
awful.  I also don't like curried syntax: with f{x=0, y=1} or f(0, 1),
the brackets clearly delineate the arguments.  Curried syntax makes this
much less clear (particularly when mixed with infix operators).  I find
most Haskell programs unreadable for this reason.
(To be fair, I think much of SML's syntax is also awful).

> * You would of course have to extends records with optional fields,
>   with creates new problems of overloading.

This is certainly true.  Possibly we could simplify the problem by only
allowing optional arguments in records used as parameter lists.

> >  1.  List.fold_right (List.fold_right IntSet.add) lists IntSet.empty

> Now let's write it with labels
>    List.fold_left lists ~init:IntSet.empty
>      ~f:(fun set l ->
>            List.fold_left l ~init:set ~f:(fun set x -> 
> IntSet.add x set))


>    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.

This is taste again, but I'm tempted to ask "Are you serious"???
Patrick's version is clearly more readable.  Better still would be to
get rid of some qualified names and use more concise names:

  foldr (foldr IntSet.add) lists IntSet.empty

Brevity can make programs easier to read.

> For me it was really revealing to hear
> from program transformation researchers in Haskell (who use fold for
> their transformations) that they didn't use it directly in actual
> programs.

That's potentially interesting, but did you ask what they used instead?
Maybe they used list comprehensions or monad syntax.

To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr