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
