Browse thread
Re: [Caml-list] Future of labels
-
Yaron M. Minsky
-
Jacques Garrigue
-
Judicael Courant
- Markus Mottl
- kahl@h...
- Chris Hecker
-
Judicael Courant
-
Jacques Garrigue
[
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: | Eric C. Cooper <ecc@c...> |
| Subject: | Re: [Caml-list] Future of labels, and ideas for library labelling |
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