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
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-29 (19:56)
From: Manuel Fahndrich <maf@m...>
Subject: RE: [Caml-list] Future of labels

I use label in classic mode, mostly to disambiguate arguments of the
same type and a little bit for documentation.

To see if I could do with modern mode, I tried to compile my current
code base with -modern. This seems to not be too bad, except for 2
things, one being a show stopper:

1) The standard library requires ~f: labels on many function arguments.
That seems silly. I basically had to add ~f: to many places where it did
not add disambiguation (f is not a very explicit name). I can see that
for partial applications that might be useful, but still I found this a
bit annoying.

2) If some library function requires a function argument with labeled
arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
and I happen to have a function around that would do the right fold
operation, except that it is unlabeled or has different labels, then I'm
stuck. I have to write an eta conversion. Why isn't an explicit cast to
change the labels of a function sound? I tried that and it didn't work.

Other than the above, it seems that a casual user like me could move
from classic to modern, especially if there are some further benefits
like partial applications in different orders.  One thing that needs
improvement though are the error messages. Because the compiler tries to
reorder arguments etc., forgetting a label spits out really whacky
messages like, this function expects too many arguments.

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