> Unfortunately, there are probably many such buggy macros, since I don't think
> most people have a clear idea when to copy properties when using
> datum->syntax.
This is key, and unfortunately I’m becoming more and more convinced
that there’s no one good answer in the presence of the relatively
complicated copying and merging semantics. Personally, I think it
would be better if syntax properties weren’t automatically copied
as part of macroexpansion at all. This leads to situations like
this:
(define-syntax-rule (define/print id val)
(begin (define id val)
(println id)))
If a syntax property is attached to the definition itself (that is,
“on the parens”), then it will be copied onto the (begin ...) form,
which is arguably wrong. The properties really ought to be transferred
to the (define ...) form, but even if they are manually transferred
via datum->syntax, they’ll end up being duplicated.
The situation is further complicated by the special syntax-original?
property, which can only be copied over using datum->syntax, which
means it’s impossible to preserve without also bringing along all
the other properties that might exist, but it’s often important to
maintain to make tools like Check Syntax work properly. I’ve mostly
tried to copy syntax properties when possible instead of using the
'original-for-check-syntax property, but perhaps the latter should
be preferred to avoid the other issues.
In light of these things, I have no idea how to “correctly” handle
properties in macros, and I’ve spent a great deal of thought trying
to figure it out.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
