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 JAA32375 for caml-redistribution@pauillac.inria.fr; Fri, 17 Mar 2000 09:08:10 +0100 (MET) Resent-Message-Id: <200003170808.JAA32375@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 SAA03659 for ; Wed, 15 Mar 2000 18:04:35 +0100 (MET) Received: from isil.localdomain (visitor5.maya.com [192.70.254.187]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA18088; Wed, 15 Mar 2000 18:04:22 +0100 (MET) Received: by isil.localdomain (Postfix, from userid 1000) id 550E2369FC; Wed, 15 Mar 2000 12:04:45 -0500 (EST) Sender: prevost@isil.localdomain To: Pierre Weis Cc: Jacques Garrigue , caml-list@inria.fr Subject: Re: Syntax for label, NEW PROPOSAL References: <39ADCF833E74D111A2D700805F1951EF180144F2@RED-MSG-06> <20000315121549A.garrigue@kurims.kyoto-u.ac.jp> <20000315145830.22463@pauillac.inria.fr> From: John Prevost Date: 15 Mar 2000 12:04:45 -0500 In-Reply-To: Pierre Weis's message of "Wed, 15 Mar 2000 14:58:30 +0100" Message-ID: <87k8j4p3ki.fsf@isil.localdomain> User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 17 Mar 2000 09:08:10 +0100 Resent-To: caml-redistribution@pauillac.inria.fr As usual, best most consistent idea is at the end. Please forgive my rambling. Pierre Weis writes: > The real problem is that fixing the code makes no good at all to its > readability (at least that's what I would say): > > # let sum l = List.fold_right fun:begin fun x acc:y -> x + y end acc:0;; > val sum : 'a -> int list -> int = > > It seems that, in the ``modern'' mode, application of higher order > functions is now denoted by a new kind of parens opening by > ``fun:begin fun'' and ending by ``end''. This is extremely explicit > but also a bit heavy (in my mind). Whoa. You can't just use fun:(+)?? There's a new acc label that's used for folds? I might have argued that fun: (or an alternative which isn't a reserved word, which I would support) isn't so bad to type. But with the labeled argument to the argument of the HOF, this is too much. As for the other semantic badness (which I actually think is syntactic badness to some degree) let's see what we can do: > -- syntactically identical patterns and expressions now may have > incompatible types: > # let f ?style:x _ = x;; > val f : ?style:'a -> 'b -> 'a option = > > As a pattern on the left-hand side x has type 'a, while as an > expression on the right hand side it has type 'a option I think this could be made sane by a reform of how the optional arguments work. There are a couple of interesting possibilities: # let f ?style:x _ = x;; - val f : ?style:('a option) -> 'b -> 'a option # let f (style:x : 'a option) _ = x - val f : style:('a option) -> 'b -> 'a option In the first case, the type of an optional labelled argument is always an option. (This makes sense in the context of what I'll say about arguments with default values below.) In the second case, any labelled argument with an option type becomes an optional argument. This has the disadvantage that it's impossible to have a required option argument. But one might argue that this interpretation makes sense. The first is dirty because there are two kinds of special arguments (optional and non-optional). The second because it gets into the type system. I think the second must lose, since "knowing" that something is an option type is complex. > -- some expressions can be only written as arguments in an application > context: > # let f ?style:x g = ?style:x;; > ^ > Syntax error > # let f ?style:x g = g ?style:x;; > val f : ?style:'a -> (?style:'a -> 'b) -> 'b = I think you have to consider this sort of thing in the context of "application involves labelled arguments now" and "this syntax is part of application syntax and argument pattern syntax, not expressions or arbitrary patterns". It is a little dirty, but survivable. A syntax which made it more obvious what was going on might be nice. I might write: # let f ?style x g = ?style x Syntax error (label in non-application position) # let f ?style x g = g ?style x - val f : ?style 'a -> ?style ('a -> 'b) -> 'b Now, ?label is a special token that changes the meaning of application. To some degree, like methods on objects. ? would "bind" more closely than application, because it's sort of like an infix. But like #, it's more of a special effect on the following symbol. This is why I write: fooobj #method val instead of fooobj#method val when I use the object syntax. > -- the simple addition of a default value to an optional argument may > trigger a typechecking error: > > # let f ?(style:x) g = g ?style:x;; > val f : ?style:'a -> (?style:'a -> 'b) -> 'b = > > # let f ?(style:x = 1) g = g ?style:x;; > This expression has type int but is here used with type 'a option Okay. This is where my thought about changing the way this works comes in. From the point of view of the called function, an optional argument with a default value is not optional at all! From the outside, of course, it is. But what if we did it like this: # let f ?(style:x) g = g ?style:x;; - val f : ?style:('a option) -> ((?style:'a option) -> 'b) -> 'b = # let f ?(style:x = 1) g = g ?style:x;; - This expression has type int but here is used with type 'a option # let f (style:x = 1) g = g ?style:x;; - This expression has type int but here is used with type 'a option # let f ?(style:x = Some 1) g = g ?style:x;; - val f : ?style:('a option) -> ((?style:'a option) -> 'b) -> 'b = # let f (style:x = Some 1) g = g ?style:x;; - val f : style:('a option) -> ((?style:'a option) -> 'b) -> 'b = What's going on here? The idea is that ? forms *always* require an option as their value, and the bound value is always an option. When you pass a value with: foo (?style:x) foo must have type: foo : (?style:'a option) -> 'b Note that I have both optional and non-optional argument syntax above with default values. Above, we see how changes effect local code in our function. (As expected, if we cause the type of the bound variable to change, the function breaks. Otherwise it doesn't.) What happens to people outside? Well, if we switch from a ? form to a non-? form, we're removing the implicit optionizing of the argument. That is: # let f (?style:x) = x;; - val f : ?style:('a option) -> 'a option # let f (style:x) = x;; - val f : style:'a -> 'a # let f (?style:x = Some 5) = x;; - val f : ?style:('a option) -> 'a option # let f (style:x = 5) = x;; - val f : ?style:int -> int Now, what's going on here? The ? in the type relates only to whether the argument is required or not. When the argument is declared with ?, this must be an option! When it is declared without ?, it may be anything. Come to think of it, this doesn't work either. It makes everything keep working as long as you keep the external type the same--but I just realized that telling the difference between labels that should be "optioned" and labels that shouldn't is hard. Okay. One last try. What if we drop back one and say that there is only one kind of labeled argument, written in this way (for my sake writing this): # let f ?style x = x;; - val f : ?style 'a -> 'a Okay. So how to optional arguments work? # let f ?style x () = x;; - val f : ?style 'a -> unit -> 'a # f ();; - : '_a option = None # f ?style (Some 27) ();; - : int option = Some 27 What's going on here? Well--let's extend the syntax to cover default arguments: # let f (?style x = 5) () = x;; - val f : ?style int -> int # f ();; - : int = 5 # let f (?style x = None) () = x;; - val f : ?style 'a option -> 'a option # f ();; - : '_a option = None and again, for reference: # let f (?style x) () = x;; - val f : ?style 'a -> 'a # f ();; - : '_a option = None So how is this happening--what's the interpretation? Oh shoot. This doesn't work either. I was going to suggest that you can always leave out a label, and that the default value will be substituted in, or if you didn't give a default, None will be substituted in. But that doesn't account for the top case above. One possibility is that it doesn't make sense to use a non-option default value: # let f (?style x = 5) () = x;; - val f : ?style int -> int * Warning: default value is not an option # f ();; f ?style None ();; ---- This expression has type 'a option but is here used with type int # f ?style 3 ();; - : int = 3 This is consistent, but sort of weird. It does certainly provide a fairly simple model of what optional arguments are, though. The only nastiness is that you need to do extra typing for each optional value given. I think this is a reasonable price to pay for sanity. # let f (?style x = Some 5) () = x;; - val f : ?style int option -> int option # let g (?style Some x = Some 5) () = x Warning: this pattern-matching is not exhaustive. Here is an example of a value that is not matched: None - val g : ?style int option -> int = # f ();; - : int option = Some 5 # g ();; - : int = 5 Of course, this is all radically different from O'Labl, so it will never happen. John.