[Moved to the dev list.]
At Sat, 06 Aug 2011 07:25:00 -0400, Neil Van Dyke wrote:
Feature request... I'd *really* like to see compile-time checking of
keyword arguments whenever that is possible.
If compiler knows what procedure will be called, and the procedure uses
keyword args in the usual way, then I'd like the compiler to report an
error when the call site, say, uses a keyword arg that the procedure
doesn't support. Likewise with required keyword args that are missing.
As a second feature request, would be nice if, when the compiler (or
JIT) can determine the procedure, if it could optimize the keyword args
the same as if they were positional args. I don't know how much the
compiler/JIT is doing already, but the static error-checking that it
misses make me suspect the compiler is not optimizing this.
The compiler proper knows nothing about keyword functions and function
calls. They're implemented by macros and expanded away into plain
functions and applicable structures.
Instead, argument checking can be pushed into the macro expansion of
keyword arguments. The idea is that `(define id lambda with keyword
arguments)' can bind `id' as syntax that checks and optimizes
first-order uses of `id'.
In more detail,
(define f (lambda (a [b 1] #:c c #:d [d 3]) ))
expands to
(define (core a have-b? b c have-d? d)
(let* ([b (if have-b? b 1)]
[d (if have-d? d 3)])
))
(define proc
(make-keyword-procedure (lambda (core
(define-syntax (f stx)
(if ... application looks ok?
(core ) ; direct call; no keyword checking or packaging
(begin
... issue warning ...
(proc ; existing protocol
so that
(f 0 1 #:c 2)
expands to
(core 0 #t 1 2 #f #f)
The macro approach has some drawbacks:
* It's not quite as general as a warning from the compiler's
optimization pass, which can detect some higher-order uses through
copy propagation and inlining. A first-order check covers most cases
in practice, though.
* Macros don't compose as nicely. Because of the way that macro
expansion is ordered in a definition context, `define' can't force
the expansion of its right-hand size to check whether it expands to
`lambda'. Instead, `define' can only recognize immediate `lambda'
forms. Again, that's probably good enough to be useful in practice.
* The `class' and `unit' forms expect `define' to bind a variable and
not syntax, because they rewrite definitions based on the connection
between an identifier with `define' and an identifier written in a
signature or a `public' clause.
To avoid this problem, the `define' form can require some
cooperation from definition contexts. A definition context that is
implemented via `local-expand' declares its willing to work with the
non-variable expansion by giving its context representation the
`prop:liberal-define-context' property. The internal-definition
contexts that are built into `lambda, `let', etc., all set that
property, while the `class' and `unit' forms do not.
* Reflection creates the usual sort of trouble:
(define f (lambda (#:x x) '))
(namespace-variable-value 'f #f #f
(variable-reference-namespace
(#%variable-reference)))
I don't mind weakening reflection at this level; it seems ok to say
that `define' creates a syntax binding for keyword functions (in a
liberal definition context).
* Mutation creates deep trouble:
(define f (lambda (#:x x) ))
(set! f (lambda (#:y y) y))
(f #:y 12)
One option is to disallow `set!' on an identifier that is bound to a
keyword-accepting procedure. That seems awkward, and it seems like
it would compose badly. I'm not as willing to sacrifice `set!' as I
am to sacrifice reflection.
Another possibility is to redirect the `set!' on `f' to the
underlying `proc', and somehow make the optimized call to `core'
happen only when `proc' is never mutated. Due to the order of macro
expansion, whether `f' is mutated is not necessarily known when a
call to `f' is expanded. The expansion of a call to `f' would have
to embed the condition that `proc' is not mutated.
We already have `#%variable-reference' to reflect information about
variables into an expressions; to make it work in all definition
contexts, `#%variable-reference' must be generalized to work with
local variables, but that's a relatively minor change. Then, a
`variable-reference-constant?' procedure can report the constantness
of a variable.
With those pieces, and when redirecting mutations of `f' to `proc',
a call to `f' could expand to
(if (variable-reference-constant? (#%variable-reference proc))
(core )
(proc .))
In some cases, especially for local bindings, the compiler can
statically
