> I don't believe this argument. I got the labeled and nonlabeled
> versions of Markus Mottl's PCRE library and looked at their respective
> sizes; the labeled versions had significantly less code (10-20% I think)
> than the unlabeled. It also dealt better with that name mess caused by
> optional parameters in the old PCRE interface causing it to read better
> IMO.
The PCRE library was my first "guinea pig" for using labels - and I think
that it was a fairly successful experiment. At least in my opinion (and
Brian's above) it made the code much more transparent - not only to me as
developer but especially to the users.
I think that there are some specific domains where labels are really most
helpful: applications that can be heavily parameterized clearly benefit
from both default arguments (makes function application much less painful)
and label names (makes use of functions with fat interfaces much more
understandable).
It seems obvious to me that GUI-libraries (though, I don't know much about
GUI-programming) and many others that are tailored for a specific purpose
(e.g. string matching) belong into this domain.
On the other hand, I have to admit that I never use labels with the
standard library. This may be partly due to accustomization to "classic
style", but definitely also, because the standard library is not
"specialized" enough (it wouldn't be "standard" then): there are only very
few functions that take numerous "flags" and "options". The "implicitely
agreed on" order of parameters seems to be clear enough to me.
Additionally, I also find labels a bit cumbersome to use with higher-order
functions. That's why I generally prefer "classic mode" over "label mode".
Since there were some voices that nearly seemed to ask for taking out
labels as a whole, I wonder what alternatives there are for, e.g.,
implementing optional arguments, which I consider as a very big "complexity
saver".
I have experimented a bit now with other ways, but haven't found anything
only closely as convenient as "labels" to do it. I have tried objects
(painraiser for the developer and also a bit slow due to dispatch for each
method call to change "parameters") and also functions with lists of
parameters, where the parameters are polymorphic variants (no need to
define an extra type). The latter also requires some amount of masochism
on the side of the developer and application is still noticably slower.
I also tried to find other additions to the language that fit better to the
"core", but whenever I wanted to refine an idea (e.g. something similar to
records that allow default values), it "converged" towards labels...
It is fully understandable that many people are happy with the core
language + module language alone and want it to stay untouched. When I
started using OCaml (having used C++ before), I knew nothing about
functional programming and came up with stupid questions like "why don't
you implement the standard library using objects?". Thanks to this mailing
list and this wonderful language, my point of view underwent a dramatic
shift (also raising my interest in theory to a level which made me take a
course on formal semantics *voluntarily* (!) ;-)
But what I also like about this language is that it is a dynamic process:
it does not stand still! (SML looks like a boring snail in comparison).
And somehow magically, neither the "OO"-addition nor the "label"-addition
seem to require any "incompatible" change to the core.
So I really do not understand the point of the quarrel on labels here -
whoever needs them (and wherever) can use them, but nobody is forced to do
so! Though I avoid them with the standard library, I do not see where
anybody could be harmed by them. I guess the growing heat in this thread is
mostly due to irrational fears that somebody might enforce labels in the
default mode, which, I think (and hope ;-), will never happen...
Best regards,
Markus Mottl
-- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Wed Mar 22 2000 - 19:02:45 MET