[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macros expanding into definitions
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?
No. Furthermore the only way it could signal an error, in light of
R4RS section 4.1.5 and the last paragraph of section 1.3.2, is if
the unspecified object returned by (if #f #f) signalled an error
when it was stored into or fetched from the location denoted by x.
I think this would violate the spirit of section 1.3.2, although
not the letter.
Usually I say that the variable is bound but not assigned,
and that a reference to an unassigned variable is an error.
I prefer not to say that a variable bound by lambda or let etc is
assigned, absent a use of set!. If variables bound by lambda or
let were said to be not unassigned, it would be reasonable to
infer that they have been assigned. Then students would be even
more likely to become confused about binding versus assignment
than they already are.
The terminology I use is similar and has a similar problem.
I say that a variable bound by the (define x) syntax is bound
but undefined, and that it is an error to refer to an undefined
variable but not an error to assign to it. The virtues of this
terminology are that it makes sense when the purpose of the
(define x) syntax is to remove a previous top-level definition
of x or to hide an outer definition of x, and it also corresponds
to the model used in the formal semantics of R4RS section 7.2 and
mentioned in the last paragraph of section 5.2.1. (No accident,
that.) The defect of this terminology is that the DEFINE keyword,
which is mostly used for the combined purpose of binding and
definition, can also be used for binding alone, without definition.
Although this is confusing, it seems to be consistent with the
R4RS, which speaks of variables as being bound or unbound, and
(so far as I can see) never speaks of variables being defined or