Alex Shinn <alexsh...@gmail.com> writes:
> Seeing as how (cond) is currently non-standard, it's the
> other way around - you have to provide evidence that it's
> useful in macros. Since by definition you're expanding
> a macro whose return value is undefined, I think this is
> likely a corner case (and possible evidence that the macro
> was poorly thought out to begin with if it may sometimes
> be defined and sometimes undefined).
Not all expressions are evaluated for their return values. Some are
evaluated solely for their effects, and of course these are the only
expressions where (cond) or (begin) makes sense.
For example, consider a convenience macro to define a structure type.
It expands to a sequence of definitions, one of which is the
constructor. In the structure specification, each field may provide an
optional `valid?' predicate. One of the jobs of the constructor is to
make sure that its arguments are valid.
One reasonable way to do this is to include a `cond' in the expansion of
the constructor which contains one clause for each field that provides
the optional `valid?' predicate. This `cond' would be evaluated solely
for its effect, namely to raise an error if any predicate fails.
However, the structure specification may not have included any field
predicates, in which case the macro would most naturally generate
(cond).
Alternatively, instead of putting all the argument checks into one
`cond', we could instead produce a sequence of `cond's with one clause
each, or perhaps a sequence of `if's. In this case, the macro would
naturally generate (begin) if no field predicates were provided.
Of course, it is not hard to work around these seemingly pointless
prohibitions, just as it would not be hard to write
(if (null? xs) 0 (apply + xs))
instead of
(apply + xs)
but I don't understand why we should have to. What's the compelling
argument on the other side that justifies these annoyances?
Thanks,
Mark
