-
Notifications
You must be signed in to change notification settings - Fork 1
KeywordProposal
dylan and clos' function congruency rules complicate function subtyping, decrease extensibility, and preclude conveniencies. parameter keywording, defaulting, and typing are conflated.
- make things convenient.
- make things simple.
- support incremental development.
- features should be orthogonal as possible.
- assume dynamic compiler.
- pay as you go.
parameter naming is orthogonal to specialization. parameter defaulting is orthogonal naming. for a given function, any of its parameters can be optionally named with a key which becomes part of the function's interface. non key parameters have their position as implicit keys.
parameter syntax:
paramspec ::=
,name ['|' ,type]]
,keyword ,default ['|' ,type]] |
(,name ,keyword ,default) ['|' ,type]] |
default ::=
,expression |
'.'
type ::=
,expression |
('...' ,expression) |
'...'
keyword ::=
c+':'
argument syntax:
keyed arguments appear after all non-keyed arguments. keyed arguments include an optional value with the default value being #t.
dispatch:
- determine canonical parameter numbering across all methods
- canonicalize (aka correlate) actual arguments with parameter numbers
- flag clashes between key and non-key parameters ???
- find applicable methods based on
- required arguments present and
- (isa? arg spec)
- sort applicable methods
key parameters with defaults
(dm sub (d|<seq> s|<seq> start:0|<int> (last end: (len s))|<int>) ...) (sub x y) (sub x y end: 1)
boolean key parameters
(dm close (s|<out-port> flush?:#f) ...) (close flush?:)
does this violate principle of least surprise?
are there ways to have key and non-key parameters collide between methods?
is this preventing certain static analysis?
this mechanism assumes that the argument/parameter correlation machinery can be optimized aways using whole-program optimization.
should be pay as you go. biggest overhead must be paid in dynamic key parameter case.