more syntax silliness

more syntax silliness

[Lynn Winebarger]

You can still get dynamic redefinition of syntax:

(define tmp
  (let ((x 5))
    (list
      (lambda (y) (set! x y))
      (lambda () x)
      (lambda (exp)
          (syntax-case exp ()
	  ((_ z) (with-syntax ((x2 (datum->syntax-object (syntax _) x)))
		   (syntax '(z x2)))))))))

  
(define setx (car tmp))
(define getx (cadr tmp))
(define-syntax foo (caddr tmp))

> (foo bar)
(bar 8)
> (setx 3)
> (let-syntax ((baz (caddr tmp)))
    (display (baz bar))
    (newline)
    (setx 'different)
    (display (baz bar))
    (newline)
    (display (foo bar))
    (newline))
(bar 3)
(bar 3)
(bar 3)
>  (foo bar)
(bar different)

    Now here's the fun part:
> (setx 2)
> (let-syntax ((baz (caddr tmp)))
    (display (baz bar))
    (newline)
    (let-syntax ((foo (let ()
			(setx 3)
			(caddr tmp))))
      (display (baz bar))
      (newline)
      (display (foo bar))
      (newline))
    (display (baz bar))
    (newline))
(bar 2)
(bar 2)
(bar 3)
(bar 3)
> (setx 2)
> (let-syntax ((baz (caddr tmp)))
    (display (baz bar))
    (newline)
    (let-syntax ((foo (let ()
			(setx 3)
			(caddr tmp))))
      (display (foo bar))
      (newline)
      (display (baz bar))
      (newline))
    (display (baz bar))
    (newline))
(bar 2)
(bar 3)
(bar 3)
(bar 3)
> 

    I don't know why the first and the second don't have the same output.  
That is, it appears the inner foo's definition doesn't get evaluated until
that foo is actually used.  This seems to me a mistake in Chez, but I could be
wrong.

Lynn




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: more syntax silliness

[Lynn Winebarger]

On Monday 19 August 2002 10:54, Lynn Winebarger wrote:
>  [example of correctly dynamically changing macro expansions deleted]
> 
>     I don't know why the first and the second don't have the same output.  
> That is, it appears the inner foo's definition doesn't get evaluated until
> that foo is actually used.  This seems to me a mistake in Chez, but I could be
> wrong.

    In case anyone was wondering, it's a bug in Chez.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: more syntax silliness

[Marius Vollmer]

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.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: more syntax silliness

[Lynn Winebarger]

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