[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
macros expanding into definitions
** From: "Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>
** From: "Mark Friedman" <markf@martigny.ai.mit.edu>
**
** The initial (and I thought primary) motivation for all this was to
** make internal defines consistent with top-level defines. The above
** rules do not do this. For example, the above disallows:
**
** (define x 0)
** (define (foo)
** (set! x 1)
** (define x 2))
** (foo)
** x
**
** It is not disallowed, it rewrites into
**
** (define x 0)
** (define (foo)
** (let ((x))
** (set! x 1)
** (set! x 2)))
** (foo)
** x
OK. I misunderstood the part about not allowing references before
definitions. I thought that references included assignments.
** This does not seem consistent to me with the top-level behavior of:
**
** (define x 0)
** (set! x 1)
** (define x 2)
** x
**
** ... I just don't see that the semantics that
** people have presented for internal defines is particularly consistent
** with top-level defines.
**
** I think they are, but you have to understand top-level defines
** differently. Imagine that top-level is wrapped in a LET that binds
** all the variables that are defined, and that the defines are just
** assignments. This is consistent with one of the options that the
** report mentions.
**
** But this is exactly what people are asking for internal DEFINE!
Sure, I see that. But you're changing internal defines to work like
top-level defines. I always saw top-level defines as a bit of kludge
to make REP loops convenient. I don't like the blurring of the
assignment-definition distinction that top-level defines create.
** In other words, the programs that you have shown are not analogous.
**
** (define x 0)
** (set! x 1)
** (define x 2)
** x
**
**
** is not the top-level equivalent of
**
** (define x 0)
** (define (foo)
** (set! x 1)
** (define x 2))
** (foo)
** x
**
** but of
**
** (define (foo)
** (define x 0)
** (set! x 1)
** (define x 2)
** x)
**
** (foo)
**
** which behaves the same way.
I understand, but the point I was making was that my equivalence is
one that naive users might make. Naive users often view procedure
execution like macro expansion. Viewing it that way I think that my
equivalence is reasonable.
I know that using the 'naive user' argument is often specious, but in
this instance I think that it is reasonable given that it is their
confusion that seemed to bring up this issue in the first place (at
least this incarnation of this issue).
-Mark