[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: portable code walkers vs. portable code

Bleah....  Defining new evaluable objects opens up a whole can of worms
that I don't even want to *think* about.  (I would personally be happier
if things like vectors that are subtypes of common were defined to be
self-evaluating objects, and leave implementation-specific datatypes to
have implementaton-specific meanings....)

Fortunately CLtL is fairly concise about defining what forms are valid in
all implementations, so a code walker could indeed detect this kind of
non-standard usage.  Likewise, a code walker could detect when you
reference a non-standard lambda keyword (but probably not detect
non-standard syntax for supplying defaults or whatever in the lambda
list).  The thing that really bothers me, though, is the possibility that a
((portable code) walker) could fail to process a piece of portable code
because the implementation saw fit to expand a standard macro into
something that contains references to implementation-specific syntax
extensions, such as new special forms, nonstandard forms, and strange
lambda list syntax.  As the manual stands now (p 58), it at least
*mentions* that implementors should avoid the first two, but doesn't say
anything about avoiding lambda list syntax extensions in this situation.
I'm all for making the warning a bit stronger and prohibiting all three