[Prev][Next][Index][Thread]
Re: Is Dylan a functional language?
On Wed, 10 Oct 2001 16:14:21 +1300, Bruce Hoult <bruce@hoult.org> wrote:
>
> Gwydion d2c does a good job of turning keyword arguments into cheap
> positional arguments if:
>
> - you don't use #all-keys
> - the call is dispatched directly to a known function
>
> If you call an unknown function, or go through a generic function
> dispatch (one that isn't optimized away), then all sorts of
> expensive things happen -- basically keyword arguments are then
> passed as a (heap allocated) vector with even arguments being the
> keyword and odd arguments being the value and then a wrapper
> function goes through and checks all the keywords and marshalls them
> into posisional arguments for the actual function.
I kind of wish that the DRM was a little stricter in the way that
method declarations work. For example, this is currently legal:
define generic quux (o :: <number>, #key foo, bar);
define method quux(o :: <integer>,
#key foo = o * o,
bar = foo * o)
foo
end method quux;
define method quux(o :: <float>,
#key bar = o * o,
foo = bar * o)
foo
end method quux;
Since Dylan specifies left-to-right evaluation order of its arguments,
we get an annoying interaction with keyword defaults that depend on
the value of prior arguments, and the order of the keyword list in
different method specifications. This is why d2c has to cons for
keywords in a gf dispatch.
It would be nice if a Dylan compiler could reject the method
quux(<float>) as having a different keyword argument list than the
generic function declaration. This would permit the overhead of
keyword arguments to get optimized away every time, since the compiler
would know that keywords always come in the same order.
For sealed domains, the compiler ought to be able to recognize and
give a warning for badly-ordered keyword lists. That's probably a
medium-sized d2c hacking project though, and I'm just a little too
busy to be able to tackle it myself.
Neel
Follow-Ups:
References: