* Re: more syntax silliness
2002-08-26 21:53 ` Marius Vollmer
@ 2002-08-26 22:30 ` Lynn Winebarger
0 siblings, 0 replies; 4+ messages in thread
From: Lynn Winebarger @ 2002-08-26 22:30 UTC (permalink / raw)
Cc: guile-devel
On Monday 26 August 2002 16:53, Marius Vollmer wrote:
> Lynn Winebarger <owinebar@free-expression.org> writes:
>
> > In case anyone was wondering, it's a bug in Chez.
>
> Do we inherit the bug? Our psyntax.ss comes straight from Chez,
> AFAIK.
I do not know. It comes from lazily evaluating let(rec)-syntax.
(confirmed by Dybvig). Is that handled by psyntax.ss? I suppose
it is since it's definitely not in the guile core.
In any case, guile's macro system suffers from its own laziness
problems that are independent of syntax-case. I was just trying
to get a better grip on how macros are supposed to expand,
rather than report a possible bug in Guile.
That infrastructure can then be used for a clean module system,
where you can import variables and macros from module A,
and they will continue to reference variables and macros in module
A. But I've been stymied by the specification of hygienic macros
by Dybvig's TSPL and R5RS as they refer to "where" a macro
is defined, but what they mean is "where" it is bound for it's
"current" usage. You'll notice the examples I gave show how
this wording can be misinterpreted. But now I've got a pretty
good idea of how it works. I've written a pattern matcher and
pattern expander (in Scheme), now I've just got to implement a
rudimentary macro expander that handles hygeine and referential
transparency. Once I've got that working, I can confirm my
understanding of syntax-case, and hand compile them into
C.
By the way, is there any good reason that the tree codes
("special symbols") can't have their number encoded only
the top 16 bits, rather than in bits 7->3 and then the top
16 bits too? This would make it easier to add tree codes that
are handled in exactly the same way as the core ones are now,
and should require only minimal changes to eval.
At the bottom is an email between Dirk and I (at DIrk's
encouragement). It shows why top-level bindings have to have a
dual nature (I sent it to Dirk for workbook/compilation/evaluation.txt).
Lynn
On Mon, 19 Aug 2002, Lynn Winebarger wrote:
> On Monday 19 August 2002 01:59, Dirk Herrmann wrote:
> >
> > Ahh. Thanks for the clarification. I assume the following:
> >
> > (define bar 5) ;; bar is normal variable
> > (define (foo x) (+ x bar)) ;; bar references normal variable, no matter
> > ;; what happens later.
> > (define-syntax bar <...>) ;; syntax 'bar' shadows the normal variable
> > ;; for further references
> > (define (baz x) (bar x)) ;; bar references syntax and gets expanded
> > (define bar 5) ;; Is this allowed and does it shadow the
> > ;; syntax?
> >
> You know, I can't actually say that what I've said is demanded by any
> specification. I just can't think of any other reasonable interpretation of
> the second line.
> That said, I tend to use Chez to test my interpretation. I could have
> sworn it choked on redefining syntax as a normal variable, but it appears
> not to, even identifier syntax. Perhaps I was testing with an older version
> before.
>
> The R5RS refers to extending the "syntactic environment" with define-syntax
> and that:
> `Let-syntax' and `letrec-syntax' are analogous to `let' and `letrec',
> but they bind syntactic keywords to macro transformers instead of
> binding variables to locations that contain values.
>
> But it also says:
> The syntactic keyword of a macro may shadow variable bindings, and local
> variable bindings may shadow keyword bindings.
>
> However, shadowing a variable implies you've got 2 different scopes. If
> you reused the same location for the macro binding as for the variable binding,
> it's not the same as shadowing.
> This is from a Petite Chez session:
> > (define bar (lambda (x) (+ x 5)))
> > (define baz (lambda (y) (+ 10 (bar y))))
> > (define-syntax bar (syntax-rules () ((_ x) (quote x))))
> > (baz 5)
> 20
> > (define bar (lambda (x) (+ 7 x)))
> > (baz 5)
> 22
> >
> What I should do is look at the formal semantics, but it does look like
> macro bindings and variable bindings should kept separate but
> nested in each other (when lexically scoped). The "interesting" part
> would be to keep track of which top-level one to use, as it can apparently
> switch back and forth. Maybe top level variables should have 2 slots
> and a flag for which to use?
>
> Lynn
>
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 4+ messages in thread