[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