From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA27115 for caml-redistribution@pauillac.inria.fr; Tue, 21 Mar 2000 15:36:03 +0100 (MET) Resent-Message-Id: <200003211436.PAA27115@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA08068 for ; Mon, 20 Mar 2000 19:26:38 +0100 (MET) Received: from julie.univ-savoie.fr (univax.univ-savoie.fr [193.48.120.32]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA29727 for ; Mon, 20 Mar 2000 19:26:38 +0100 (MET) Received: from univ-savoie.fr (lama-d134.univ-savoie.fr [193.48.123.134]) by julie.univ-savoie.fr (8.9.3/jtpda-5.3.3) with ESMTP id TAA46011 ; Mon, 20 Mar 2000 19:25:50 +0100 (CET) Sender: raffalli@univ-savoie.fr Message-ID: <38D66D00.7245D221@univ-savoie.fr> Date: Mon, 20 Mar 2000 19:25:04 +0100 From: Christophe Raffalli Organization: Laboratoire de =?iso-8859-1?Q?Math=E9matiques?=, =?iso-8859-1?Q?Universit=E9?= de Savoie X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: Jacques Garrigue CC: caml-list@inria.fr Subject: Re: Syntax for label, NEW SOLUTION References: <38D35B51.8EB15DA0@univ-savoie.fr> <20000319112913P.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-From: weis@pauillac.inria.fr Resent-Date: Tue, 21 Mar 2000 15:36:03 +0100 Resent-To: caml-redistribution@pauillac.inria.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 = # 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 = 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