[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
macros expanding into definitions
Date: Tue, 1 Dec 92 17:08:53 -0500
From: "Guillermo J. Rozas" <email@example.com>
From: Pavel Curtis <Pavel@parc.xerox.com>
Date: Tue, 1 Dec 1992 11:59:14 PST
I believe that Jinx's analysis of his examples is correct, using
the transformation given in R4RS in the last paragraph before
section 7.2.1. The only clarification I would make (and I think
Jinx would agree, based on his wording) is that references to
variables with unspecified values *is* an error, but may not
*raise* an error in some implementations.
Do you think that ((lambda (x) x 3) (if #f #f)) should be an error?
Should implementations be allowed to raise an error for that (unused)
reference to x? After all, x's value is unspecified at that point.
I don't think ((lambda (x) x 3) (if #f #f)) should be an error; more
generally, I don't think referring to a variable that happens to be
bound to an unspecified value should be an error. If we were to
decide that it was an error, that would be an incompatible language
change, and some reasonable programs would break.
I think it would be better to find a different term or constraint to
describe the situation with internally and top-levelly DEFINE'd
variables. Usually I say that the variable is bound but not assigned,
and that a reference to an unassigned variable is an error.