I got a strange side effect with my silex apply hack. I was able to simplify it down to this test case where I define the two macros apply and token.
The file a.scm works:
$ cat a.scm (define gambit-apply apply) (define-syntax apply (syntax-rules (string-append) ((_ string-append list) (append-strings list)) ((_ func list) (gambit-apply func list))))
(display (gambit-apply string-append (list "a"))) (newline)
$ gsi -:s a.scm a
The file b.scm works also:
$ cat b.scm (define-syntax token (syntax-rules () ((_ name value) (cons name value)) ((_ name) (cons name '()))))
(define (b) (token "b"))
(display (car (b))) (newline)
$ gsi -:s b.scm b
But when I concatenate the two files I get an error:
$ cat a.scm b.scm > c.scm $ gsi -:s c.scm *** ERROR IN #<procedure #2>, "c.scm"@7.7 -- Unbound variable: gambit-apply
How could gambit-apply get lost?
Afficher les réponses par date
On 2012-01-17, at 5:39 AM, Sascha Ziemann wrote:
I got a strange side effect with my silex apply hack. I was able to simplify it down to this test case where I define the two macros apply and token.
The file a.scm works:
$ cat a.scm (define gambit-apply apply) (define-syntax apply (syntax-rules (string-append) ((_ string-append list) (append-strings list)) ((_ func list) (gambit-apply func list))))
(display (gambit-apply string-append (list "a"))) (newline)
$ gsi -:s a.scm a
The file b.scm works also:
$ cat b.scm (define-syntax token (syntax-rules () ((_ name value) (cons name value)) ((_ name) (cons name '()))))
(define (b) (token "b"))
(display (car (b))) (newline)
$ gsi -:s b.scm b
But when I concatenate the two files I get an error:
$ cat a.scm b.scm > c.scm $ gsi -:s c.scm *** ERROR IN #<procedure #2>, "c.scm"@7.7 -- Unbound variable: gambit-apply
How could gambit-apply get lost?
Strange indeed! I get the same error. But when the define-syntax of token is moved earlier in the file, all is OK. My understanding is that the psyntax implementation of syntax-rules calls eval when a macro is expanded (i.e. the call (token "b")) and the expression that is evaluated contains a call to apply. The environment in which eval does its evaluation has already been extended with the macro definition for apply, so the expression evaluated when (token "b") is expanded contains a call to gambit-apply. But gambit-apply will only be defined later, when the program is run!
This is a bug in the psyntax implementation, which wasn't written by me and is too complex (4.5 KLOC, and 60 KLOC after expansion!) for me to debug. Sorry!
Marc
Sascha, BH implements syntax-rules and define-macro, i.e., it has its own expander.
2012/1/17 Marc Feeley feeley@iro.umontreal.ca
On 2012-01-17, at 5:39 AM, Sascha Ziemann wrote:
I got a strange side effect with my silex apply hack. I was able to simplify it down to this test case where I define the two macros apply and token.
The file a.scm works:
$ cat a.scm (define gambit-apply apply) (define-syntax apply (syntax-rules (string-append) ((_ string-append list) (append-strings list)) ((_ func list) (gambit-apply func list))))
(display (gambit-apply string-append (list "a"))) (newline)
$ gsi -:s a.scm a
The file b.scm works also:
$ cat b.scm (define-syntax token (syntax-rules () ((_ name value) (cons name value)) ((_ name) (cons name '()))))
(define (b) (token "b"))
(display (car (b))) (newline)
$ gsi -:s b.scm b
But when I concatenate the two files I get an error:
$ cat a.scm b.scm > c.scm $ gsi -:s c.scm *** ERROR IN #<procedure #2>, "c.scm"@7.7 -- Unbound variable:
gambit-apply
How could gambit-apply get lost?
Strange indeed! I get the same error. But when the define-syntax of token is moved earlier in the file, all is OK. My understanding is that the psyntax implementation of syntax-rules calls eval when a macro is expanded (i.e. the call (token "b")) and the expression that is evaluated contains a call to apply. The environment in which eval does its evaluation has already been extended with the macro definition for apply, so the expression evaluated when (token "b") is expanded contains a call to gambit-apply. But gambit-apply will only be defined later, when the program is run!
This is a bug in the psyntax implementation, which wasn't written by me and is too complex (4.5 KLOC, and 60 KLOC after expansion!) for me to debug. Sorry!
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Marc Feeley -
Mikael -
Sascha Ziemann