From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA24129; Tue, 3 Apr 2001 16:04:17 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA24565 for caml-list@pauillac.inria.fr; Tue, 3 Apr 2001 16:04:16 +0200 (MET DST) 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 OAA20615 for ; Tue, 3 Apr 2001 14:03:06 +0200 (MET DST) Received: from sarg.Ryerson.CA (sarg.ryerson.ca [141.117.18.117]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f33C34P07881; Tue, 3 Apr 2001 14:03:04 +0200 (MET DST) Received: from sarg.Ryerson.CA (IDENT:dmason@localhost [127.0.0.1]) by sarg.Ryerson.CA (8.9.3/8.9.3) with ESMTP id IAA25790; Tue, 3 Apr 2001 08:02:59 -0400 Message-Id: <200104031202.IAA25790@sarg.Ryerson.CA> To: Xavier Leroy cc: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling In-reply-to: Your message of "Tue, 03 Apr 2001 10:52:12 +0200." <20010403105212.A15700@pauillac.inria.fr> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Apr 2001 08:02:59 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> On Tue, 3 Apr 2001 10:52:12 +0200, Xavier Leroy said: > 1- We wanted labeled and optional function arguments to be an > extension of the Caml language (just like objects, classes, and > modules to a very large extent), i.e. something that does not affect > the core ML language, and remain backward compatible with earlier > versions of OCaml. I think this is crucial for two reasons. First, > it must be possible to learn and teach OCaml incrementally, by > successive layers of increasing complexity. I agree. Java and Ada are, to me, counter-examples of this approach. Too much stuff you have to explain or tell students to ``just do this magic.... don't worry why''. I know that teachers of Java and Ada (and labeled ocaml) feel otherwise, but I've done it, read their explanations, have observed student response, and I remain un-convinced. > Second, we happen to have users that develop significant > applications in OCaml, and changing the language in incompatible > ways every other year is a sure way to piss them off. We get enough > criticism and suspicion about OCaml "changing all the time"... I agree here too. I want ocaml to gain much wider adoption, and occasional incompatible changes are not a sure recipe for this! (On the other hand, as far as I can see, all incompatibilities here would be caught at compile time and would be quite obvious and easy to fix.) > 2- With the strict label semantics of OLabl or OCaml with the > -labels option (if a label is given in the function > definition/declaration, it must be used in all applications of that > function), the only way to achieve backward compatibility (point 1 > above) is to have versions of the standard libraries that are > totally unlabeled. > But we quickly realized this was unfeasible. It's just too hard to > maintain two versions of the same libraries. I admit in advance I haven't looked at how the type-checking of labels works in the compiler. However it seems to me that it is simply a compile-time thing, so a ``label-squashing'' .mli file should be able to produce an image of a label-free library. Maybe have a different file extension - foo.cml and foo.cmi - for the two versions. But they would both use the same foo.cmo for the implementation. > 5- We considered putting compiler pragmas to select the label mode I think that if you want to keep 2 modes (and I find the arguments for at least classic mode compelling), that a pragma should be seriously considered. Having a compiler switch makes Makefiles more complicated to maintain. (I like all variation of interpretation of a file to be captured in that file.) However, like everyone else I'd prefer a single mode. It seems to me that a label mode similar to the one (Arturo?) recalled from his macro-assembler days would be more useful than either of the existing modes (although some might like to keep a pedantic mode that enforced use of labels). To use everyone's favourite example, fold: from analogy with scheme and long usage, I am comfortable with putting the function parameter first, but I always have to stop and think about the positions of the accumulator and list parameters, so it would be extremely convenient if I could say, given a signature of: fold_right: ~f(~from_list:'a->~acc:'b->'b) -> ~list:'a list -> ~acc:'b -> 'b any of the expressions: fold_right (+) [1;2;3] 0 or fold_right (+) ~list:[1;2;3] ~acc:0 or fold_right (+) ~acc:0 [1;2;3] or fold_right (+) 0 ~list:[1;2;3] or fold_right ~list:[1;2;3] ~acc:0 (fun x y -> x*3+y) or fold_right [1;2;3] 0 ~f:(fun ~from_list:x ~acc:y -> x*3+y) As I understand it, only the first 2 of these would be legal in classic mode, and none of them would be legal in label mode. Perhaps there are good typing reasons why so few of these are legal, but to me, labels would be much more useful like this than either of the existing ways. With the caveat that I haven't used label mode yet, I don't find labels in type signature any more useful as documentation than the signatures without them. Their value is in application: 1) to disambiguate parameters with the same type (this is a frequent annoyance in some work I'm doing in Java right now) and 2) to allow sane use of functions with dozens of optional parameters (such as in lablTk). Sorry if this re-opens old debates. ../Dave ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr