RE: Syntax for label, NEW SOLUTION

RE: Syntax for label, NEW SOLUTION

[Toby Moth]

[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]

( sorry if this got posted twice )

I have kept out of the label debate as I haven't had a chance to really play
with 2.99
yet, have hardly ever used OLabl, and generally feel more optimistic about
what labels
might offer me than terrified about how Ocaml might suffer. 

So, I am just throwing an ill-cautioned suggestion when I say that it looks
to me
as if  Claudio is onto something.

Would it be possible to set up something along the lines:

MyModule:foo       need labels
MyModule.foo       labels checked if used

open MyModule:    needs labels
open MyModule     labels checked if used

Then the only case where you are committed is when you are inside a module
that you are actually writing using functions that you have just defined.
But if you are using labels inside your own module then surely you can't
object
to labels......
so surely you are happy with a label enforcing mode.

I suppose then that you would be able to write

Mod1.Mod2:foo
Mod1:Mod2:foo

and it would mean the same thing. Style would suggest that you use all ':'
or all '.'.

Is this impossible to implement ?


Toby Moth

	-----Original Message-----
	From:	Claudio Sacerdoti Coen [SMTP:sacerdot@students.cs.unibo.it]
	Sent:	22 March 2000 18:15
	To:	caml-redistribution@pauillac.inria.fr
	Subject:	Re: Syntax for label, NEW SOLUTION

	On Mon, Mar 20, 2000 at 19:25:04 +0100, Christophe Raffalli wrote:
	> Ok, and I agree ! What I mean is that it could happend sooner if
there
	> was a mode that is conservetive over both modern and classic
modes. I
	> will give a first working answer ...

	There could be also another simple, backward compatible (w.r.t.
OCaml)
	solution that would get rid of the "labels in the library" fight.
	Only, I don't know if it is (semantically) feasible. Here it is:

	If I write

	 Moo.foo x a:y z;;

	or

	 open Moo;;
	 foo x a:y z;;

	or

	 let module M = Moo in
	  M.foo x a:y z;;

	than foo is label-checked as in classic mode.

	Instead, if I write 

	 open Moo in commutating mode;;  (* or something like that *)
	 foo x a:y z;;

	than foo is label-checked as in modern mode.

	So, for example, I could write

	open List;;
	open Unix as in moder mode.
	open Tk as in moder mode.

	What am I overlooking?

						C.S.C.

	-- 
	-----------------------------------------
	Real Name: Claudio Sacerdoti Coen
	Graduating students at the
	 Department of Computer Science,
	 university of Bologna
	Address: via del Colle n.6
		 S. Lazzaro di Savena (BO)
		 Italy
	e-mail:  sacerdot@cs.unibo.it
	-----------------------------------------



Toby Moth
Concorde Road, Norreys Drive, Maidenhead,
Berkshire SL6 4AG UK
Tel: +44 (0)1628 434301 Fax: +44 (0)1628 434875 Email:
tmoth@nortelnetworks.com

> NgRTEL NETWORKS
> 
> 

[-- Attachment #2: Type: text/html, Size: 7215 bytes --]

RE: Syntax for label, NEW SOLUTION

[Toby Moth]

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

I have kept out of the label debate as I haven't had a chance to really play
with 2.99
yet, have hardly ever used OLabl, and generally feel more optimistic about
what labels
might offer me than terrified about how Ocaml might suffer. 

So, I am just throwing an ill-cautioned suggestion when I say that it looks
to me
as if  Claudio is onto something.

Would it be possible to set up something along the lines:

MyModule:foo       need labels
MyModule.foo       labels checked if used

open MyModule:    needs labels
open MyModule     labels checked if used

Then the only case where you are committed is when you are inside a module
that you are actually writing using functions that you have just defined.
But if you are using labels inside your own module then surely you can't
object
to labels......
then surely you are happy with a label enforcing mode.

I suppose then that you would be able to write

Mod1.Mod2:foo
Mod1:Mod2:foo

and it would mean the same thing.

Is this impossible to implement ?


Toby Moth

> -----Original Message-----
> From:	Claudio Sacerdoti Coen [SMTP:sacerdot@students.cs.unibo.it]
> Sent:	22 March 2000 18:15
> To:	caml-redistribution@pauillac.inria.fr
> Subject:	Re: Syntax for label, NEW SOLUTION
> 
> On Mon, Mar 20, 2000 at 19:25:04 +0100, Christophe Raffalli wrote:
> > Ok, and I agree ! What I mean is that it could happend sooner if there
> > was a mode that is conservetive over both modern and classic modes. I
> > will give a first working answer ...
> 
> There could be also another simple, backward compatible (w.r.t. OCaml)
> solution that would get rid of the "labels in the library" fight.
> Only, I don't know if it is (semantically) feasible. Here it is:
> 
> If I write
> 
>  Moo.foo x a:y z;;
> 
> or
> 
>  open Moo;;
>  foo x a:y z;;
> 
> or
> 
>  let module M = Moo in
>   M.foo x a:y z;;
> 
> than foo is label-checked as in classic mode.
> 
> Instead, if I write 
> 
>  open Moo in commutating mode;;  (* or something like that *)
>  foo x a:y z;;
> 
> than foo is label-checked as in modern mode.
> 
> So, for example, I could write
> 
> open List;;
> open Unix as in moder mode.
> open Tk as in moder mode.
> 
> What am I overlooking?
> 
> 					C.S.C.
> 
> -- 
> -----------------------------------------
> Real Name: Claudio Sacerdoti Coen
> Graduating students at the
>  Department of Computer Science,
>  university of Bologna
> Address: via del Colle n.6
> 	 S. Lazzaro di Savena (BO)
> 	 Italy
> e-mail:  sacerdot@cs.unibo.it
> -----------------------------------------

[-- Attachment #2: Type: text/html, Size: 6363 bytes --]

Re: Syntax for label, NEW SOLUTION

[Claudio Sacerdoti Coen]

On Mon, Mar 20, 2000 at 19:25:04 +0100, Christophe Raffalli wrote:
> Ok, and I agree ! What I mean is that it could happend sooner if there
> was a mode that is conservetive over both modern and classic modes. I
> will give a first working answer ...

There could be also another simple, backward compatible (w.r.t. OCaml)
solution that would get rid of the "labels in the library" fight.
Only, I don't know if it is (semantically) feasible. Here it is:

If I write

 Moo.foo x a:y z;;

or

 open Moo;;
 foo x a:y z;;

or

 let module M = Moo in
  M.foo x a:y z;;

than foo is label-checked as in classic mode.

Instead, if I write 

 open Moo in commutating mode;;  (* or something like that *)
 foo x a:y z;;

than foo is label-checked as in modern mode.

So, for example, I could write

open List;;
open Unix as in moder mode.
open Tk as in moder mode.

What am I overlooking?

					C.S.C.

-- 
-----------------------------------------
Real Name: Claudio Sacerdoti Coen
Graduating students at the
 Department of Computer Science,
 university of Bologna
Address: via del Colle n.6
	 S. Lazzaro di Savena (BO)
	 Italy
e-mail:  sacerdot@cs.unibo.it
-----------------------------------------

Re: Syntax for label, NEW SOLUTION

[John Max Skaller]

Jacques Garrigue wrote:

> There is a misunderstanding here.  There are currently two
> communities, and one goal of the merger is to have a big caml
> community again.  I think that having two modes is a good way to reach
> this goal.  

	I do not: in the short term, two modes is a good compromise.
In the longer term, one language is better. I am glad for the two 
modes at present. I hope they will go away in the future.

> > o The fact that you've had to resort to "modes" at all indicates something
> > is wrong.  

> Well, before that there were two compilers.  I think this is a progress.

	I agree. Particularly, I was attracted by some of the
olabl software but was not willing to use two compilers. Now I have
the nice olabl software, and still have  my ocaml software too.
 
> > If we could come up with a semantics where labels are always optional,
> > I think I would accept things like acc in the standard library.  But
> > when you have to make a choice between optional labels and no useful
> > functionality, it's a harder sell.
> 
> Some people really want to eat the cake and still have it.

	Sure, why not?

> I already explained a while ago why it was not possible to have labels
> both optionals and commuting in a curried language.

	Sure it is. The question is whether the error messages
are readable.  Python supports 

	1) positional arguments
	2) labelled arguments
	3) default values for missing trailing positional parameters
	4) optional labelled AND positional arguments

It does not support currying, but it does diagnose missing arguments,
and such could be re-implemented as partial applications.

	FYI the rules are: for a definition:

	def f(x,y,z=1,q=2,*args, **kwds): ...

and calls

	f(1,2)
	f(1,2,3,4,5,6,7)
	f(1,z=6,y=4, extra=22)


	1) bind parameters to the given positional arguments positionally.
	If there are too many, the extra ones go into the tuple 'args' if
given,
	else error.

	2) try to bind the remaining positional arguments from labelled ones.
	If there is a duplication of labelled and positional arguments, error.
	If there are still missing required arguments, 
		then use the default if there is one,
		else error (change to 'curry' for our purposes)

	3) if **kwds is given,
		put all the labelled arguments into dictionary kwds (even those
		used to fill in required arguments)

	4) if there are excess labelled arguments and no kwds, then error.

Thousands of Python programmers use this scheme every day. 
Currying missing arguments would disable error checking,
so in Python you have to use a separate function definition.

[This could actually be fixed by sugar: use f(x, curry) to signify
intentional currying]

	I'm not suggesting to use thd Python scheme, only that
it _is_ possible to support optional commuting labelled arguments
and optional arguments, and default arguments, and variable
length argument lists and arbitrary option sets coherently.

> Do not confuse the fact of having two reasonably consitent modes with
> having only one in which any strange thing is allowed.

	Also do not confuse 'we cannot think of a synthesis of the
modes which makes sense' with 'there exists no such synthesis' :-)
 
> That sounds reasonable. I would also personally prefer "f:" to "fn:".
> My choice of labels has been driven by voices from olabl users who
> insisted that labels should be as readable as possible, but having
> short names is ok if they are readable.  Still I would not support
> reducing _all_ labels to 1 character, while it might be ok for most
> of them in the standard library.  Having a document for it is only
> bearable as long as it is standard

	Why not allow several (synonymous) labels?

	let f c: chr: character: the_really_verbose_character: c' = c'

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Syntax for label, NEW SOLUTION

[Christophe Raffalli]

Jacques Garrigue wrote:
> 
> As Xavier included `\' in his list (which surprised me a little, since
> for me '\' was taboo), I would go for it.
> 
> That is, replace ':' by '\' in terms, but keep ':' in types.
> Any counter-proposals?

I would still vote for ~ because it denotes some kind of equivalence
spcialy when you write "fun x~x -> " which fell like somthing reflexive
even if it is not symmetric.

> > - Their semantics in modern mode.
> >
> > I quite agree, their should not be two modes, because this will means
> > two communities of users and therefore at some point two standards
> > libraries because each kind of users will have different needs. This is
> > dangerous ...
> > soon there would not be only one big caml community anymore.
> 
> There is a misunderstanding here.  There are currently two
> communities, and one goal of the merger is to have a big caml
> community again.  I think that having two modes is a good way to reach
> this goal.  All this discussion just shows that this would be very
> difficult with only one mode.

Ok, and I agree ! What I mean is that it could happend sooner if there
was a mode that is conservetive over both modern and classic modes. I
will give a first working answer ...

> > But there may be a solution in three step:
> >
> > 1) Let's have only the modern mode. But let it accept any expressions
> > with no amibiguities. This means that if according to both types AND
> > labels there is a unique valid order of arguments then the compiler do
> > not complain.
> > ....
> I do not understand very well your proposal.  If you let arguments
> commute when there is no ambiguity, then this is just a big mess,
> because the concept of no ambiguity is only understood by the
> compiler. If you do not let them commute, then I do not see how this
> improves on classic mode, which already allows you to check labels
> when you want.

What I want is that it is possible to assign an unlabeled argument to a
function waiting for a labeled one. I give a simple modification of
Ocaml which seems to verify that in can compile both the programs
written for classic and modern mode.

An example with Array.blit:

> ocaml -modern
        Objective Caml version 2.99 (99/12/08)
 
# let f a x b y len = Array.blit a src_pos:x b dst_pos:y len;;
Warning: Argument without label used when waiting for a label
Warning: Argument without label used when waiting for a label
Warning: Argument without label used when waiting for a
label                                                                     
val f : 'a array -> int -> 'a array -> int -> int -> unit = <fun> 
# let g a x b y len = Array.blit a b len src_pos:x dst_pos:y;;
Warning: Argument without label used when waiting for a label
Warning: Argument without label used when waiting for a label
Warning: Argument without label used when waiting for a
label                                                                     
val g : 'a array -> int -> 'a array -> int -> int -> unit = <fun> 
                                                                      
This is a very simple trick which is a bit dirty (just look at it). I
think one could do much better, specially if unification over types had
been purely functional in Caml (then one could try to type in some way,
fail and try something else).

The main problem is that now Ocaml must print a warning when there are
more than one way to assign an unlabeled argument to a function waiting
for a labeled one. Otherwise, one of the role of labels is lost: capture
more bugs)

The List.fold_left fun:(+) does not work yet because I did not modify
the unification algorithm ... A simple solution is to ignore the
Clflags.classic in unification as no permutation are done by unification
anyway !

> > 3) For the problem of List.fold_left (+), there is a solution: tell to
> > the compiler that (+) is commutative ! Or more generally find a syntax
> > to tell that two or more arguments of the same types may be commuted
> > without changing the behaviour of the function. Then there would be no
> > ambiguities when you type List.fold_left (+) and the compiler wii not
> > complain ! There would be a problem only with  List.fold_left (/) but
> > then writing the labels explicitely may be better (or rewrite it with a
> > product).
> 
> Woa. Teaching properties of functions to the compiler would be very
> nice, but I'm afraid type checking technology is not nearly mature
> enough for that. That's a good subject for research :-)
>

Just giving yourself some indication like

val (+) : a:int -> a:int -> int 
(* same labels means permutation is irrelevant ! *)

To get less warnings should not be difficult.

-----------
-----------

Here are the diff for the 4 modified files : 
  btype.ml btype.mli typecore.ml and typecore.mli

>> diff btype.ml.ori btype.ml

247c247,284
< let extract_label l ls = extract_label_aux [] l ls
---
> let rec extract_label_aux' count hd = function
>     [] -> raise Not_found
>   | (l',t as p) :: ls ->
>       if !count = 0 && label_name l' = "" then (l', t, List.rev hd, ls)
>       else begin
>       if label_name l' = "" then decr count;
>       extract_label_aux' count (p::hd) ls
>       end
>
> let num_unlabeled_arrow ty =
>     let rec fn acc = function
>       {desc=Tarrow (l, ty, ty_fun)} ->
>         fn (if l = "" then acc+1 else acc) ty_fun
>       |       _ -> acc
>     in fn 0 ty
>
> let num_unlabeled_clarrow ty =
>     let rec fn acc = function
>       Tcty_fun (l, ty, ty_fun) ->
>         fn (if l = "" then acc+1 else acc) ty_fun
>       |       _ -> acc
>     in fn 0 ty
>
> let extract_label count opt l ls mls =
>   try
>     let (l', ls0, ls1, ls2) = extract_label_aux [] l ls
>     in (l', ls0, ls1 @ ls2, mls, false)
>   with Not_found -> try
>     let (l', ls0, ls1, ls2) = extract_label_aux [] l mls
>     in (l', ls0, ls @ ls1, ls2, false)
>   with Not_found when not opt ->
>     let count = ref count in
>     try
>       let (l', ls0, ls1, ls2) = extract_label_aux' count [] ls
>       in (l', ls0, ls1 @ ls2, mls, true)
>     with Not_found ->
>       let (l', ls0, ls1, ls2) = extract_label_aux' count [] mls
>       in (l', ls0, ls @ ls1, ls2, true)                                                                                         

>>diff typecore.ml.ori typecore.ml 

926,932c926,927
<             let (l', sarg0, sargs, more_sargs) =
<               try
<                 let (l', sarg0, sargs1, sargs2) = extract_label name
sargs
<                 in (l', sarg0, sargs1 @ sargs2, more_sargs)
<               with Not_found ->
<                 let (l', sarg0, sargs1, sargs2) = extract_label name
more_sargs
<                 in (l', sarg0, sargs @ sargs1, sargs2)
---
>             let (l', sarg0, sargs, more_sargs, unlab_args) =
>             extract_label (num_unlabeled_arrow ty_fun') (is_optional l) name sargs more_sargs
933a929,931
>           if unlab_args then
>             Location.print_warning sarg0.pexp_loc
>               (Warnings.Other "Argument without label used when waiting for a label");                                          

>> diff typeclass.ml.ori typeclass.ml
637,645c637,639
<                 let (l', sarg0, sargs, more_sargs) =
<                   try
<                     let (l', sarg0, sargs1, sargs2) =
<                       Btype.extract_label name sargs
<                     in (l', sarg0, sargs1 @ sargs2, more_sargs)
<                   with Not_found ->
<                     let (l', sarg0, sargs1, sargs2) =
<                       Btype.extract_label name more_sargs
<                     in (l', sarg0, sargs @ sargs1, sargs2)
---
>                 let (l', sarg0, sargs, more_sargs, unlab_args) =
>                 Btype.extract_label (Btype.num_unlabeled_clarrow ty_fun)
>                   (Btype.is_optional l) name sargs more_sargs
646a641,643
>               if unlab_args then
>                 Location.print_warning sarg0.pexp_loc
>                   (Warnings.Other "Argument without label used when waiting for a label");                                      

and modify like this the the end of btype.mli (I forgot to keep the
original)

val num_unlabeled_arrow : type_expr -> int
val num_unlabeled_clarrow : class_type -> int

val extract_label :
    int -> bool -> label -> (label * 'a) list -> (label * 'a) list ->
    label * 'a * (label * 'a) list * (label * 'a) list * bool
    (* actual label, value, before list, after list *)

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI

Re: Syntax for label, NEW SOLUTION

[Jacques Garrigue]

Since I do not want to flood the caml-list with messages, I answer
several messages together.  This makes the answer a bit long, but bear
with me if you are interested.

From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>

> First to clarify, there are two distinct problems with labels:
> 
> - Their syntax: Anything that let me put (or not put) spaces where I
> want will suit me. (If people are not happy with the final syntax let
> them use camlp4 :-)

That's not easy, but maybe we can find something.
After your idea of keeping `:' in types, and only change the syntax
for terms, I first thought that this would be bad, in particular this
would cause technical problems in the lexer, since we do not want a
special lexing rule for `:' anymore. However if we decide that
labels cannot have keyword names, this should be possible to work it
out at the parser level (the :label form is no longer needed).

As Xavier included `\' in his list (which surprised me a little, since
for me '\' was taboo), I would go for it.

That is, replace ':' by '\' in terms, but keep ':' in types.
Any counter-proposals?

> - Their semantics in modern mode.
> 
> I quite agree, their should not be two modes, because this will means
> two communities of users and therefore at some point two standards
> libraries because each kind of users will have different needs. This is
> dangerous ...
> soon there would not be only one big caml community anymore.

There is a misunderstanding here.  There are currently two
communities, and one goal of the merger is to have a big caml
community again.  I think that having two modes is a good way to reach
this goal.  All this discussion just shows that this would be very
difficult with only one mode.

> But there may be a solution in three step:
> 
> 1) Let's have only the modern mode. But let it accept any expressions
> with no amibiguities. This means that if according to both types AND
> labels there is a unique valid order of arguments then the compiler do
> not complain.
> 
> At this point you can use blit with
> 
> > Array.blit a src_pos:x b dst_pos:y len
> 
> If both array a and b have not the same types and
> 
> > Array.blit src:a src_pos:x b dst_pos:y len
> 
> If they have the same type.
> 
> This is reasonnable ! 

I do not understand very well your proposal.  If you let arguments
commute when there is no ambiguity, then this is just a big mess,
because the concept of no ambiguity is only understood by the
compiler. If you do not let them commute, then I do not see how this
improves on classic mode, which already allows you to check labels
when you want.

> 3) For the problem of List.fold_left (+), there is a solution: tell to
> the compiler that (+) is commutative ! Or more generally find a syntax
> to tell that two or more arguments of the same types may be commuted
> without changing the behaviour of the function. Then there would be no
> ambiguities when you type List.fold_left (+) and the compiler wii not
> complain ! There would be a problem only with  List.fold_left (/) but
> then writing the labels explicitely may be better (or rewrite it with a
> product).

Woa. Teaching properties of functions to the compiler would be very
nice, but I'm afraid type checking technology is not nearly mature
enough for that. That's a good subject for research :-)

From: Don Syme <dsyme@microsoft.com>

> I really don't see people clamouring for lots of labels in the standard
> library (besides the inventors of the language feature, who don't really
> count, for lots of obvious reasons - over exposure to the feature, over
> familiarity with the label names, a natural bent to program in a particular
> way that led them to the feature in the first place, self-selection as
> people who think the feature is the best thing ever).

Maybe they're just decent, and do not like flame wars.
I do not like either, and have to force myself to write these messages.
I can only tell you that ocaml-2.99 has a few labels less that olabl,
and that I already had comments from olabl users who thought it was "odd".
There were also several messages in this forum insisting for then fun:
label on functionals, and this is the function fold_right which
started all this discussion.

> o The fact that you've had to resort to "modes" at all indicates something
> is wrong.  The point about O'Caml is that you shouldn't have to understand
> _anything_ about labels, objects, modules or syntax modes to use the system
> as a new user.  You shouldn't have to see any labels, nor have to ask "what
> are these two modes all about", nor have to try to understand why some of
> the arguments have labels and some don't.

Well, before that there were two compilers.  I think this is a progress.

> o The "just documentation" response doesn't really hold water, because if
> the labels were just documentation, then they would different.  For example,
> "fun", being a keyword, is highly confusing and not terribly descriptive -
> any sensible prototype would probably just use "f".  And C prototypes look
> _horrible_ when you have both higher order arguments and argument names.

If you think that some labels are not that good as documentation, then
make suggestions.  Since most people will only use them as
doumentation, this should be a priority.  And if they are good
documentation, then will certainly be good to use in programs also.
The problem about C prototypes and higher-order functions is really a
problem with the way you write function types in C, not about the
variable names.

From: John Prevost <prevost@maya.com>

> If we could come up with a semantics where labels are always optional,
> I think I would accept things like acc in the standard library.  But
> when you have to make a choice between optional labels and no useful
> functionality, it's a harder sell.

Some people really want to eat the cake and still have it.
I already explained a while ago why it was not possible to have labels
both optionals and commuting in a curried language.
Even if it were possible, I would fully agree with Pierre on this
point: this is going to make programs unreadable.  If you do not
decide clearly which is your policy, then you end up with Perl!
Do not confuse the fact of having two reasonably consitent modes with
having only one in which any strange thing is allowed.

From: Damien Doligez <Damien.Doligez@inria.fr>

> I agree, and I would even go further.  I think the current labeling of
> the standard library is way too verbose.  "fun" should not be "func"
> or even "fn", but simply "f".  That's the usual name for a generic
> function.  Likewise, we should replace char:char with c:char and so
> on (maybe even the predicate function in List.for_all should be
> labeled f).
> 
> Also, in the List module, I found this:
> 
>     val nth : 'a list -> pos:int -> 'a
> 
> This is really bad design, unless the goal is to confuse the reader
> (two different names for the same number).  It should be either
> 
>     val nth : 'a list -> n:int -> 'a
> 
> or
> 
>     val posth : 'a list -> pos:int -> 'a
> .
> 
> I think we need to develop a systematic set of abbreviations (and a
> document to explain it) that will allow us to limit almost all labels
> to be at most one character in length.  It would (at least partially)
> solve the problem of expression cluttering that we have with the long
> labels currently in the library.  As a side-effect, it would also
> solve the problem of keywords as labels: there isn't any keyword of
> length 1.

That sounds reasonable. I would also personally prefer "f:" to "fn:".
My choice of labels has been driven by voices from olabl users who
insisted that labels should be as readable as possible, but having
short names is ok if they are readable.  Still I would not support
reducing _all_ labels to 1 character, while it might be ok for most
of them in the standard library.  Having a document for it is only
bearable as long as it is standard

The choice of pos: rather than n: in List.nth was driven by an attempt
at homogeneizing labels with other modules, in which pos: is used.
But too much homogeneity is not always good.  If the meaning does not
exactly match, then it might be better to use another label.

Remark that if we are going to do such extensive changes, we must have
a coordination to choose labels, and that it will take some time.

> This is an excellent suggestion, and I have implemented it (as of
> version 2.99+12) : I replaced the command-line option "-modern" with
> "-label".  I kept "-modern" as an alias to "-label" for the time
> being, but I certainly hope we'll retire it before we release 3.00.

You're a bit fast Damien. Personally I would really prefer -commute.
Labels are also available in classic mode, it is just that they do not
commute there.

Also a very personal comment: why do you persist in erasing the date
from the version number? I really think it helps to trace back
problems :-)

Best regards to everybody,

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: Syntax for label, NEW SOLUTION

[Christophe Raffalli]

First to clarify, there are two distinct problems with labels:

- Their syntax: Anything that let me put (or not put) spaces where I
want will suit me. (If people are not happy with the final syntax let
them use camlp4 :-)

- Their semantics in modern mode.

I quite agree, their should not be two modes, because this will means
two communities of users and therefore at some point two standards
libraries because each kind of users will have different needs. This is
dangerous ...
soon there would not be only one big caml community anymore.

But there may be a solution in three step:

1) Let's have only the modern mode. But let it accept any expressions
with no amibiguities. This means that if according to both types AND
labels there is a unique valid order of arguments then the compiler do
not complain.

At this point you can use blit with

> Array.blit a src_pos:x b dst_pos:y len

If both array a and b have not the same types and

> Array.blit src:a src_pos:x b dst_pos:y len

If they have the same type.

This is reasonnable ! 

But can this be implemented ? I think that this is what people wants for
labels (at least what I want). And if this is not implementable at this
time let's wait for a solution ! 

2) let's turn error messages about labels ambiguities into warning and
-modern option into an option to print or not these warnings. This is
more reasonnable and conform to the usage in a lot of programming
languages.

3) For the problem of List.fold_left (+), there is a solution: tell to
the compiler that (+) is commutative ! Or more generally find a syntax
to tell that two or more arguments of the same types may be commuted
without changing the behaviour of the function. Then there would be no
ambiguities when you type List.fold_left (+) and the compiler wii not
complain ! There would be a problem only with  List.fold_left (/) but
then writing the labels explicitely may be better (or rewrite it with a
product).

 


 
-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI