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-11 (14:07)
From: Anton Moscal <msk@p...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
On Wed, 11 Apr 2001, Jacques Garrigue wrote:

> The situation seems to have calmed down a bit. Or is it just that
> there is another more active thread?
> Anyway, I think that the conclusion is not very far. At least, we have
> collected all known problems about labels, and tried to answer them.
> Here is a summary of the plan I tried to draw from many people's
> contributions (and my own experience and convictions :-)):
> * remove labels from standard libraries
> * make label mode the default (and practically unique) mode;
>   this preserves compatibility with ocaml 2.x
> * slightly extend it to allow non-labelled complete applications of
>   functions: this is non-ambiguous, but keep a warning for purists,
>   and also because of the slight mismatch between program text and
>   untyped semantics
> * put some labels in alternative versions of a few libraries
>   (List, Array, Unix). Access to these libraries would use already
>   existing ways: "open Stdlabels", "module Unix = Lunix"

If you are going to make new versions of the standard libraries, it's a
good moment for doing some unifications of these libraries:

for example will be good if all "collection" modules (List,Array,
String, Map, Set, Hashtbl) will have similar sets of functions:

for examples - fold's, map's, etc in String,
iteri, mapi, foldi in String, Array, Map, Set etc.

or, for example, types 'a List.t, 'a Array.t for simplifing of usage
Array and List as parameters for functors. etc.

or include functions print:

instead of print_string etc. string -> string -> int char -> char -> int

And many others changes of the same kind.

To unsubscribe, mail  Archives: