macros expanding into definitions

[jar@cs.cornell.edu (Jonathan Rees)]

   Date: Tue, 1 Dec 92 17:08:53 -0500
   From: "Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>

      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.

   I agree.

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.