Here's a relevant paper describing OCaml typing: http://caml.inria.fr/pub/papers/garrigue-labels-ppl01.pdf
I tried your example, translating it to OCaml (I used 3.09.2). Seems like OCaml insists on optional parameters to be given as arguments before labeled ones: (* val app : (x:'a -> 'b) -> 'a -> 'b = <fun> *) let app f x = f ~x:x (* val f1 : x:'a -> 'a = <fun> *) let f1 ~x = x (* val f2 : ?y:int -> x:'a -> int = <fun> *) let f2 ?y:(y=0) ~x = y (* val f3 : ?y:int -> ?z:int -> x:'a -> int = <fun> *) let f3 ?y:(y=0) ?z:(z=240) ~x = z (* None of the following compiles in OCaml .. (* The type of this expression, '_a -> '_a, contains type variables that cannot be generalized *) let a = app f1 (* This expression has type ?y:int -> x:'a -> int but is used here with type x:'b -> 'c *) let b = app f2 (* This expression has type ?y:int -> ?z:int -> x:'a -> int but is used here with type x:'b -> 'c *) let c = app f3 *) (* This does compile though. *) (* val id : 'a -> 'a = <fun> *) let id x = app f1 x Looks like OCaml doesn't initialize optional arguments for you, or do any sort of sub-typing. Thanks, PKE. Swaroop Sridhar wrote: > Jonathan S. Shapiro wrote: > >> On Wed, Mar 11, 2009 at 1:26 PM, Pal-Kristian Engstad >> <[email protected]> wrote: >> >>> Keyword arguments is a very important feature, especially when dealing >>> with low-level code as well as in game-code.... >>> >> Every feature is very important to someone. >> >> I was initially concerned that keyword arguments would require >> overhauling the type checker, but I now see that this is not true; >> [...] >> If we then impose the rules: >> >> 1. Arguments are partitioned into those with defaults and those without. >> 2. Keyword args can always be used to specify values for default arguments >> 3. If *any* keyword arg is used to specify a mandatory parameter, then >> *all* >> mandatory parameters must be given with keyword args >> >> Swaroop: what am I forgetting here, if anything? >> > > Functions with labeled arguments are not a problem, but my understanding > is that functions with default arguments will put us to a fundamentally > more complex type system which involves sub-typing. > > For example, consider the definition: > > (define (app f x) (f arg=x)) > > All of the following applications are legal > > (define (f1 arg) arg) > (define (f2 arg arg1=0) arg1) > (define (f3 arg arg1=0 arg3=250) arg3) > > (app f1) > (app f2) > (app f3) > > If we type `app' as (fn (fn arg:'a -> 'b) -> 'b), we must use sub-typing > to permit the above applications. > > We can type the above expression without sub-typing by using a > constraint similar to has-field. However, this has-arg constraint is > more complicated than has-field since it must constrain a set of fields > and require that all other fields of the function have default > arguments. > > A generic solution to this problem does involve sub-typing. For example, > the following expression cannot be typed without a sub-typing system: > > ((if #t f2 f3) arg=25) > > > it's simply that definitions and declarations must agree. > > Assuming that the above problem is somehow solved, should the default > values be written both at the definition and the declaration, or is it > just that the labels for the arguments should agree at definition and > proclamation? I guess requiring the initializers to be the same in all > proclamations (which might span various modules) might be difficult, and > we might impose the C++ like default arguments only once rule, or > default arguments at definition rule. > > Also, are the initializers required to be values, or can they be > expressions? If initializers can be expressions, I guess they are > evaluated at every call? We should have a restriction to rule out > (mutually) recursive initializers like > > (define (f arg=(f)) arg) > > Swaroop. > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > > -- Pål-Kristian Engstad ([email protected]), Lead Graphics & Engine Programmer, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North, Santa Monica, CA 90404, USA. Ph.: (310) 633-9112. "Emacs would be a far better OS if it was shipped with a halfway-decent text editor." -- Slashdot, Dec 13. 2005. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
