[bitc-dev] Syntax: keyword arguments

[Pal-Kristian Engstad]

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
>> <pal_engstad at naughtydog.com> 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
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>   


-- 
Pål-Kristian Engstad (engstad at naughtydog.com), 
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.