Re: [Caml-list] Future of labels, and ideas for library labelling

["Eric C. Cooper" <ecc@cmu.edu>]

I have been using OCaml for about a year, having "converted" from SML,
and have only written a few thousand lines of code in it. I have only
used labels when forced to, in order to interface to labltk and lablgtk.

The label technology is an impressive piece of work -- it seems like a
very clean extension to the core language and clearly increases the
expressive power for a certain programming style. But the examples of
this style that I have seen, namely Tk and Gtk, seem to have been forced
on us by "foreign" packages.  Would a "native" library need labels as
badly? I would hope not -- it seems that OCaml should allow much nicer
interfaces than those in C and C++, but maybe I am just being naive.

So far, I see labels not as the "Right Way", but as a necessary evil for
dealing with complex real-world APIs.  Somewhat like a network firewall
-- you need more baggage to deal with the outside, but things can be
cleaner and more lightweight in an environment you control.

I don't agree that labels are valuable simply to document interfaces. 
Choosing names for interfaces is a very important part of software
engineering, and we already have to do it for types and values.  Having
to come up with good names (labels) for function parameters makes this
harder.  Having a lot of ~f, ~x, and ~list labels doesn't add enough
clarity, IMO, to compensate for the cluttering up of every function
call.

I have also noticed a "viral" aspect to labels.  If I start using a
labelled library, it tends to "infect" the client code that I write (in
order to gracefully call (f ~arg) for example).

Finally, I don't see continuation of two modes as a bad thing. Rather,
it is evidence of a healthy language with real users.  Look at gcc, with
its "-traditional" and "-ansi" modes.

Eric Cooper
ecc@cmu.edu
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr