[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Assymetry between argument-passing and value-returning
In view of the recent semi-suggestions that the logical similarity between
argument passing and value receiving be institutionalized in Common Lisp,
perhaps we ought to review some of the reasons as to why we *didn't* do
it in the first place.
For one thing, I believe the need to mediate the argument spectrum could be
done on either side -- the defining side or the calling side -- but that
doing it on the defining side is simpler. For example, it is possible
to correct a definition *** in one place *** that fixes up a whole
slew of differing calls (e.g., some calls passing 3 args, some passing
5 args, etc). Similarly, we would keep the calling side "simple" even when
multiple return values are expected (i.e., no &optional or &rest, and
no destructuring). For the cases where some dynamic variation *is*
desirable, well, APPLY permits full freedom on the caller side for argument
passing, and MULTIPLE-VALUE-LIST permits full freedom on the caller side for
receiving values; of course, these "full freedom" capabilities are consy,
but they aren't expected to be very important.
The case offered as a potential example needing (or rather,"wanting") some
caller control over the argument spectrum -- simple WHEREIS and extended
WHEREIS -- seems to be a clear case of buggy design. For example, suppose
a caller passes 6 arguments at a time when the 4-argument-only version
is resident. What could possibly be expected? Should one assume that the
extra two argments didn't convey any information, and can safely be discarded?
If so, then what is the point of the 6-argument version. If one takes the
obvious tactic of having the 4-argument version admit two optional aguments
and run a fatal error if either argument is passed in [or even perhaps
autoload the 6-argument version when the optionals are passed in] then
there is no "4-argument" version; both are in fact 6-argument functions,
although one of them is biased against the 5th and 6th args.
In short, if one wants downward compatibility, he has to design the low-end
function to do something reasonable with callers who request high-end
features.
-- JonL --