Make macro-aux safe for other things together with syntax-case

[dpk]

If you set the macro-aux of a macro outside of (chibi syntax-case), it would previously case syntax to think that it was a pattern variable and try to substitute it, even if the macro-aux was being used for something else.

This patch fixes that by wrapping pattern variable values in an extra typed box and checking that it has the right type before deciding that it’s actually a pattern variable.

[dpk]

Test case:

> (import (chibi syntax-case) (chibi ast) (only (chibi) current-environment))
WARNING: importing already defined binding: define-syntax
WARNING: importing already defined binding: let-syntax
WARNING: importing already defined binding: letrec-syntax
> (define-syntax foo (syntax-rules ()))
> (macro-aux-set! (cdr (env-cell (current-environment) 'foo)) 'bar)
> #'foo
;; with this patch:
foo
;; without this patch:
ERROR in cadr on line 6 of file ./lib/init-7.scm: cdr: not a pair: bar

[mnieper]

The aux field was introduced just for consumption by syntax-case. If it is intended that it is used for other purposes as well, the patch makes sense. A possible use case outside of syntax-case can be the implementation of identifier properties à la SRFI 213. (And if this is done, syntax-case and syntax can be implemented in terms of identifier properties - pattern variables become keywords with a certain property - so syntax-case and syntax won't need access to the aux field anymore.)

[dpk]

How can the aux field be used to implement SRFI 213?

[mnieper]

How can the aux field be used to implement SRFI 213?

I thought I would just drop this random idea and then someone else would figure out whether it would work. 😃

I had in mind that when define-property is used to add a property to an identifier, the identifier is rebound to a macro that is "identifier syntax". Then, the aux field of the macro is used for meta-information. This would need some amendment to free-identifier? because the meaning of the rebound identifier as tested by this relation shouldn't change.

But I haven't thoroughly thought about it so expect the devil in the details

[dpk]

Yes, my initial thought was you must mean something like that, but it would have the same problem as my approach in #820, no? (I assume this is what you mean with the problem with free-identifier=?)

[mnieper]

Yes, my initial thought was you must mean something like that, but it would have the same problem as my approach in #820, no? (I assume this is what you mean with the problem with free-identifier=?)

I didn't mean that problem (but that is probably still a problem). I just mean that redefining the binding of an identifier (from a variable to a keyword) would break free-identifier=? if this rebinding by define-property is not understood and ignored by free-identifier=?.

So it may be better to attach an aux field to every kind of bound object, not only macros.