Browse thread
RE: [Caml-list] Future of labels
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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. -Maf ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr