On Fri, Jan 6, 2012 at 5:03 PM, Mark H Weaver <m...@netris.org> wrote:
>
> 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).
Please take this to the scheme-reports list if you really
want the standard changed.
However, you would need actual macro examples to
convince me. I can't see how you could arrive at the
scenario you're describing. Assuming you've filtered
out the fields that have predicates into pred-fields,
then you would expand into something like:
(define (constructor fields ...)
(begin
(expand-validate-field pred-fields) ...
<normal-body>))
where each expand-validate-field would be something
like
(unless predicate (error "field predicate failed"))
and possibly this would be inlined above instead of
a separate macro. Alternately, if you don't want
individual error messages but a single error then
you expand into
(define (constructor fields ...)
(unless (and (expand-predicate pred-fields) ...)
(error "some predicates failed"))
<normal-body>)
where again there's no problem because the empty
(and) is valid.
I think the only reason to use cond would be the
aesthetics of _not_ having any side-effecting expressions,
i.e. you could expand into
(define (constructor fields ...)
(cond
((expand-predicate pred-fields) (error "invalid field")) ...
(else <normal-body>)))
where the normal body is the "else" clause
of the cond when no errors occurred, but in
this case the cond is never empty (and always
returns a value or errors).
But I repeat, take this to the list, and polish up
your arguments because you have to convince
the whole group.
> 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?
This analogy is meaningless, but for the record
you should be using fold or reduce here.
--
Alex
