Re: Syntax for label, NEW SOLUTION

[Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>]

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