[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
optional arguments
> Date: Fri, 3 Apr 87 16:47:09 EST
> From: Jonathan A Rees <JAR@mc.lcs.mit.edu>
>
> I have a different optional arguments proposal, which people should keep
> in mind as an alternative:
>
> Don't make any change to the syntax of LAMBDA. Instead, just introduce
> a new special form for taking apart rest arguments. Example:
>
> (LAMBDA (A B . R)
> (OPTIONAL ((X 1) (Y (+ X 5))) R
> -body-))
This appears to be more of a destructuring form than one restricted to
defining optional arguments. Would you allow the (OPTIONAL ...) to
appear anywhere or just directly inside a LAMBDA as its body? Must
the second "argument" (R) be the name of a "rest" arg?
> [...]
> I think this gets most of the benefits you want without making LAMBDA
> hairy. It provides parameter list destructuring and error checking in a
> nice orthogonal way, and is only a little bit more verbose than hairy
> LAMBDA-isms. And it can be implemented in straightforwardly as a macro.
It apparently only allows destructuring at the top level of a list.
My suggestion can also be implemented straightforwardly as a macro.
> [...]
> Effiency note: the mythical "sufficiently clever compiler" can avoid
> consing the rest-list if there's only the one reference to R. I think
> this would be a very straightforward transformation.
I like this notation, but not the idea that its efficiency depends on
the cleverness of the compiler, since that inhibits using such
features in portable code. It would require a compiler to determine
whether the declared rest arg R were otherwise referenced from within
the body of the procedure in order to approach the efficiency a dumb
compiler could get with my approach.
On the other hand, if one customarily wrote
(LAMBDA (A B . R1)
(OPTIONAL ((X 1) (Y (+ X 5)) . R2) R1
-body-))
with the variables R1 and R2 having the same name, then a preprocessor
for LAMBDA could "look ahead" for an OPTIONAL form in its body and
determine that R1 could possibly have but one use. This would be a
fairly localized test. (But is it proper for one macro to assume that
another macro has not been redefined?)
Regards,
David Bartley