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: [Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-03 (09:34)
From: Judicael Courant <Judicael.Courant@l...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Hi Xavier,

I understand the strong need for upward compatibility for O'Caml (note
however that the time I have spent porting programs from an O'Caml
version to another I negligible compared to the time I have spent
designing/writing/debugging them) but I disagree with you on some

> 1- We wanted labeled and optional function arguments to be an
> extension of the Caml language (just like objects, classes, and
> modules to a very large extent), i.e. something that does not affect
> the core ML language, and remain backward compatible with earlier
> versions of OCaml.

I am not sure the case of classes and objects is the same as the case of
labels. As for modules I do not think they are an extension, even if
their power is underused. Map and Set for instance are useless if you do
not know how to apply a functor.

>  I think this is crucial for two reasons.  First,
> it must be possible to learn and teach OCaml incrementally, by
> successive layers of increasing complexity.

I already said I disagree on this. We have a one semester course here
that does not use the standard library because currified functions are
ignored. Does that mean you should remove currified functions from the
standard library?

> But we quickly realized this was unfeasible.  It's just too hard to
> maintain two versions of the same libraries.

Why? I do not see the problem with the tool I have suggested? (a tool
taking as input an interface file with labels and generating both the
interface file without labels and a stub implementation).

> And everyone who writes
> a Caml library and wants it to be used as widely as possible while
> taking advantage of labels would also need to maintain two versions.

I disagree with you: if I write an object-oriented library, I do not
feel the need to provide a non-object-oriented version of it. Users will
use objects or will not use the library. I think the same applies for

(+33) (0)1 69 15 64 85
"Montre moi des morceaux de ton monde, et je te montrerai le mien"
Tim, matricule #929, condamné à mort.
To unsubscribe, mail  Archives: