Am Mo., 16. März 2020 um 22:17 Uhr schrieb Lassi Kortela <
xxxxxx@lassi.io>:
> How do you call `bar' in Common Lisp's/Gauche's model so that `x' and
> `y' do not receive any values but `foo' receives the value `3'?
>
> How would you handle a procedure that can arbitrarily many positional
> arguments and keyword arguments?
>
> With Kawa's model this is easily doable; with CL's/Gauche's model I
> don't see how.
IIRC there is no way to do that in the CL model. Another reason to
prefer all-#f default values for optional arguments.
The CL model prioritizes simplicity (of one kind) - it re-uses the rest
argument, which presumably existed years or even decades before keyword
arguments, to implement kwargs.
As discussed earlier, IMHO the CL semantics are already too nuanced for
reasonable real world scenarios. While implementing kwargs as a whole
new type of argument is more orthogonal, it complicates the language
even more than the CL style.
This is just my opinion, but I am strongly in favor of having a total
complexity budget for a language. That means each feature should justify
its complexity (which is also a good reason to be skeptical of having
kwargs at all).
Kwargs are solving a real problem as evidenced by the fact that people
are continually implementing their own ad hoc versions of them (or
thinking about doing so, as with several current SRFIs). But so far,
those can all be covered with the most trivial version of kwargs. It may
be that more features are needed (in particular, allow-other-keys) but
the examples demonstrating their necessity are fewer and not as clear.
The fancier kwargs are getting to be like method combination, multiple
inheritance and the meta-object protocol in CLOS - every part is
reasonable and logically specified in isolation, but when considering
the entire system one starts to doubt whether this is really the
simplest and soundest way to solve any practical problem.
Let's try to keep at least this discussion at a technical level.
At least from that point of view, the CL model doesn't seem to provide anything but syntactic sugar over an extra plist argument.
> The optimization possibilities Per mentioned don't work with CL's model,
> which just looks like an ordinary plist argument in disguise.
> Marc
Can't (define/kw (foo a b #!key c d) ...) store information about its
argument list and the compiler check calls with read-time keywords at
the "right" positions? Is there a reason it can't optimize (foo 1 2 :d
4) if :d is read as a self-evaluating keyword object?
If the procedure `foo' is known at the call site, a good compiler can optimize a lot. Even plist arguments encoding keywords can be handled in an optimized way.
In general, `foo' is not known at the call site or `foo' is defined in some other module, for which no compile-time information is available. With the CL model, `foo' has to be treated as an ordinary procedure taking 4 arguments. Otherwise, as I have described in my first post in this thread, section 4.1.3 of the R7RS-small would be violated.
Marc