Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Didier Remy <remy@m...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> writes:

Salut Jacques,

I am not sure I understand all your conclusions: 

> 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

So far, I understand. 

> * 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

I do not understand much of this sentence. 
Moreover, I am a bit worried by  the use of the words I've emphasized.

> * 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"
> * also add alternative labelled versions for the few functions with
>   more than 4 arguments in the standard library (e.g. String.blit')

Since these two points are the same, that is, provide alternative labeled
versions of some functions, could they be solved in the same way (introduce
a prime version of module M v.s. introduction primed definitions of
identifier f), so as to avoid dupplicating conventions.

Also, before you chose names for the primed modules, can you find a uniform
convention (c.f. Stdlabels and Lunix that you keep using in examples).  Or,
could these modules have the same name but be defined in a subdirectory of
the stdlib?

Cheers,

        Didier
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr