Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: to have labels or not
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-03-27 (17:22)
From: John Max Skaller <skaller@m...>
Subject: Re: to have labels or not
Jacques Garrigue wrote:
> This is a reasonable argument.  However, by discussing with olabl
> users (many of them being originally ocaml users) I really got the
> feeling that the fact to have to write labels for standard library
> functions didn't bother them. 

	It bothers me, because it will create a lot of extra clutter,
and force me to 'fix' thousands of lines of code. I'm having enough
trouble coping with the weak error messages in classic ocaml,
without being confused by additional ones.

	I often make systematic changes (replace one type with another),
and I rely on compiler diagnostics to find all the uses to allow
me to upgrade the relevant code. This works well in C and C++,
but not so well in ocaml (for a variety of reasons).

	My small experiment with polymorphic variants sent me
running for my backup copy. :-(

	[I replaced a large 'type X = | v1 .. | v2 .. ' with three
smaller (non-polymorphic) variants, and created three polymorphic
variants each covering two of theses cases. Had this worked,
it would have greatly improved my code, since many functions
are only interested in 2/3 of the cases -- the other 1/3 cannot occur
dynamically, and it is really bad writing default handlers 
like '| _ -> assert false' because this prevents the compiler
diagnosing missing cases. Anyhow, I couldn't get it to work
after two days, so I gave up. I couldn't make head or tail
of the error messages half the time

FYI: the case involed is a language 'term', of which there are three
kinds: ones that only exist at compile time and are replaced on
evaluation (sugary constructions), ones that are the same at 
compile and run time (things like integers), and ones that only
exist at run-time (like dictionaries represented as hashtables).

> So before deciding whether you want to stay classic or go to commuting
> label mode, you might just give it an (extensive enough) try.

	How? The modes are incompatible.
> > So here's a suggestion. Get rid of classic mode.
> > But have TWO complete standard libraries:
> >
> >       module Classic = .. put classic modules here ..
> >       module Olabl = put labelled versions here
> We thought about that.  And even tried it before releasing 2.99.
> I am the one who pushed against this solution, because I felt this
> would really cause a community split.

	The community started out split, and has been brought closer together
by the ocaml/olabl merger. But the community is _still_ split because
usage of the modes is incompatible: we have two languages and one
The way I see it, two libraries and one language reduces the split
I do _not_ see this as idea -- OR permanent. But having two libraries
is a temporary hack to allow a full merger of the languages, and to
on an acceptable compromise to get one library.
> The problem is not just the standard library.
> If you do not have classic mode, then it means that everybody will
> have to write all labels. If you have a look at LablGL, you will see
> that I use there plenty of non-optional labels, and very few optional
> ones. I'm pretty sure people would start asking me to remove them.

	I don't think so. The greatest feeling here is with the
standard libraries, because we all have a vested interest in
out current code, and our programming habits.
> The whole point is: the user (not the implementor) should decide.
> And in practice it is better to decide on a program-wide rather than a
> per-module basis (as some suggested).

	I don't agree: I do not wish to choose between two 'almost the same'
languages. But I regularly chose which library components to use
in an application, so this is just the same choice I usually make.

> The only weakness of this approach is if you copy some code from a
> file in classic mode to one in commuting label mode (or reverse).
> Then you have to add/remove labels by hand.  But then this is also a
> way to understand the code better :-)

	In a production environment, one is NOT interested in
understanding 'the code', one is trying to USE the code
WITHOUT understanding it. This is the very point of abstraction
and information hiding.

	For example, I use Pcre, I do NOT understand the code,
and I don't want to. I'm too busy to waste time on such details,
I prefer to trust Markus -- complain if something doesn't work
as advertised, or ask for help if I don't understand.

	BTW: I'm not claiming two libraries is the right solution 
either. I really don't know. I am glad a first step has been
made to merge the two systems. Thank you!

John (Max) Skaller,
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper
download Interscript