optional arguments

[David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>]

> 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