Output syntax objects have lots of brag-internal syntax properties attached to them #35

The syntax objects produced by a grammar's parse function have a bunch of brag-internal syntax properties on them. There's a hide-or-splice property, a splice-rh-id property, a hide property, a kvpair property, and also a property with the name of the matching grammar rule for each rule that matched the syntax object. I'd like for my language's read-syntax function to avoid exposing these properties in the syntax objects it produces. Can brag strip these properties out or hide them in the resulting parsed syntax objects it produces? The brag-internal properties like hide-or-splice are easy to fix, they can just be changed to uninterned symbols so they're hidden. But the grammar rule properties - can brag just remove all of those or avoid adding them in the first place? I don't really want to leak the details of my language implementation's grammar rule names.

The syntax objects produced by a grammar's `parse` function have a bunch of `brag`-internal syntax properties on them. There's a `hide-or-splice` property, a `splice-rh-id` property, a `hide` property, a `kvpair` property, and also a property with the name of the matching grammar rule for each rule that matched the syntax object. I'd like for my language's `read-syntax` function to avoid exposing these properties in the syntax objects it produces. Can `brag` strip these properties out or hide them in the resulting parsed syntax objects it produces? The `brag`-internal properties like `hide-or-splice` are easy to fix, they can just be changed to uninterned symbols so they're hidden. But the grammar rule properties - can brag just remove all of those or avoid adding them in the first place? I don't really want to leak the details of my language implementation's grammar rule names.

I'd like for my language's read-syntax function to avoid exposing these properties in the syntax objects it produces … I don't really want to leak the details of my language implementation's grammar rule names.

As with #34, it’s not apparent to me that brag is overtly misusing the syntax-property system. (If you have evidence otherwise, happy to look, etc.) Reasonable people may differ, but I don’t like to enforce the deletion of possibly useful information out of some abstract notion of tidiness. Decisions like that seem better delegated to language implementors, not arrogated to myself out of misguided omniscience.

> I'd like for my language's `read-syntax` function to avoid exposing these properties in the syntax objects it produces … I don't really want to leak the details of my language implementation's grammar rule names. As with #34, it’s not apparent to me that `brag` is overtly misusing the syntax-property system. (If you have evidence otherwise, happy to look, etc.) Reasonable people may differ, but I don’t like to enforce the deletion of possibly useful information out of some abstract notion of tidiness. Decisions like that seem better delegated to language implementors, not arrogated to myself out of misguided omniscience.

Part of the issue is that due to racket/racket#4182, trying to remove the properties myself with syntax-property-remove doesn't work as it should. Calling (syntax-property-remove stx 'splice-rh-id) for example won't remove the property unless I work around the bug by explicitly setting the property to a non-false value first with (syntax-property-remove (syntax-property stx 'splice-rh-id #true) 'splice-rh-id). Arguably that's not really brag's responsibility or problem, it just seems really easy to fix and I'm happy to fix it myself. I'd just have to add (define splice-rh-id (string->uninterned-symbol "splice-rh-id")) somewhere in brag and change every occurrence of (syntax-property stx 'splice-rh-id) to (syntax-property stx splice-rh-id), and similarly for the other core brag syntax property keys.

Part of the issue is that due to racket/racket#4182, trying to remove the properties myself with `syntax-property-remove` doesn't work as it should. Calling `(syntax-property-remove stx 'splice-rh-id)` for example won't remove the property unless I work around the bug by explicitly setting the property to a non-false value first with `(syntax-property-remove (syntax-property stx 'splice-rh-id #true) 'splice-rh-id)`. Arguably that's not really `brag`'s responsibility or problem, it just seems really easy to fix and I'm happy to fix it myself. I'd just have to add `(define splice-rh-id (string->uninterned-symbol "splice-rh-id"))` somewhere in `brag` and change every occurrence of `(syntax-property stx 'splice-rh-id)` to `(syntax-property stx splice-rh-id)`, and similarly for the other core `brag` syntax property keys.

I consider my work on brag complete. I remain interested in reports of bona fide bugs. I weigh feature requests on a cost–benefit curve that boils down to “would this be widely useful?” and “do I want to volunteer my time for this?” Consistent with a notion of completeness, the answer to the second question must increasingly be no. (But see #31 and #32.)

Your requests here and in #34 and #36 are too specialized and too difficult for me to tangle with, I’m afraid. (BTW behavior that also exists in ragg arises from code that I didn’t write, and touching that code always becomes an archeological excavation into the Tomb of the Ancient Rabbit and Unshorn Yak)

As nicely as possible — I think your best option is to fork brag and pilot it to your next destination (as I myself once did with ragg)

I consider my work on `brag` complete. I remain interested in reports of bona fide bugs. I weigh feature requests on a cost–benefit curve that boils down to “would this be widely useful?” and “do I want to volunteer my time for this?” Consistent with a notion of completeness, the answer to the second question must increasingly be no. (But see #31 and #32.) Your requests here and in #34 and #36 are too specialized and too difficult for me to tangle with, I’m afraid. (BTW behavior that also exists in `ragg` arises from code that I didn’t write, and touching that code always becomes an archeological excavation into the Tomb of the Ancient Rabbit and Unshorn Yak) As nicely as possible — I think your best option is to fork `brag` and pilot it to your next destination (as I myself once did with `ragg`)

That makes sense. I'll give it some thought and tinkering. I really do appreciate all the work you've put into brag and Beautiful Racket. The former is a delight to use and the latter a joy to read.

That makes sense. I'll give it some thought and tinkering. I really do appreciate all the work you've put into `brag` and Beautiful Racket. The former is a delight to use and the latter a joy to read.

Labels Milestones

Output syntax objects have lots of brag-internal syntax properties attached to them #35