At Thu, 21 Apr 2016 11:45:08 -0700 (PDT), Jack Firth wrote: > The documentation for syntax properties states that if a macro sets a syntax > property during expansion then instead of the expanded syntax having only the > set value, it has a cons tree containing that value and any previous values > set for that same property. As I understand it, this means it's impossible > for > macros to remove syntax property values during expansion. Why is that? I > don't > understand the purpose of it, and it makes working with custom syntax > properties a bit unpleasant API-wise.
The original intent was to relieve a macro implementor of the burden of appropriately propagating properties such as 'origin and 'disappeared-use. Since that very early decision, the role and potential uses of properties have expanded. I can see how it would make sense to not propagate and merge some properties. In the same way that properties can now be attached as preserved or not, we could and an option for specifying whether properties are are propagated/merged or not. If it's useful, we could even allow a combining function to be associated with with either a property value or a property key --- although a general combining function wouldn't work with a preserved property. Any thoughts on those details? (FWIW, as I look back at the documentation, I think it needs clarification on the point that only properties of the immediate syntax object for the input and output of a macro are merged. Properties are not merged on any syntax object within the immediate syntax object.) -- 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.
