What would happen if you add a property as ephemeral and then add it again as non-emphemeral? It would just change modes? I guess we could add a "is this property added to this syntax object ephemerally or not?" predicate?
I feel like this variant is more error prone (as you can forget one syntax-property call site and then things will work sometimes and not work other times) and it would be trickier to debug unless it came with some kind of special printing support syntax objects somehow so you'd immediately see that a property had the wrong mode. It does feel more "natural" in a sense, tho. But perhaps that is not to be trusted. Robby On Sat, Mar 5, 2016 at 5:14 PM, Matthew Flatt <[email protected]> wrote: > Your characterization suggests another possibility: an optional > argument when setting a property to indicate whether the setting is > ephemeral. > > That is, we would still have one function for ephemeral or not, but the > difference would be selected by an extra argument, instead selected by > the shape of the key. Along those lines, preservation would be a > feature of the setting, instead of a feature of the key. > > This approach provides a slightly better explanation for 'paren-shape > --- it's attached as non-ephemeral by the reader --- and it avoids > changing the notion of equality for property keys. Then again, we'd > have a different compatibility issue: anything other than the reader > that adds 'paren-shape would need to explicitly add the property as > non-ephemeral, otherwise it would revert (in a sense) to the pre-v6.3 > behavior. > > Any opinion on this new option? So far, I like it the best, but I > haven't thought about it as much as the others. > > At Sat, 5 Mar 2016 16:35:32 -0600, Robby Findler wrote: >> I like your third option best, too. It makes sense to me to think of >> this as two separate, but related operations (add ephemeral property, >> add preserved property) and to avoid adding a new primitive function, >> but just generalize one of the arguments for the existing one. That >> is, the code that chooses to put the property on is the one that >> deserves to choose whether or not the property is preserved. This >> choice means that properties can be used as a robust way for macros to >> cooperate with each other (which wouldn't be the case for the first >> option) and that seems useful. >> >> Robby >> >> >> On Sat, Mar 5, 2016 at 4:23 PM, Matthew Flatt <[email protected]> wrote: >> > I agree that both of those are potential issues. I'd expect problems, >> > but I don't know how common the problems would be. >> > >> > I think we would probably end up wanting ephemeral properties, anyway, >> > so it makes more sense to be to leave ephemeral as the default and add >> > a non-ephemeral option. >> > >> > At Sat, 5 Mar 2016 15:25:51 -0600, Robby Findler wrote: >> >> Is avoiding the change to preserve of all properties a backwards >> >> compatibility concern or a performance one? (I wouldn't ask, except >> >> there were a surprising number of bugfixes for the source location >> >> change.) >> >> >> >> Robby >> >> >> >> >> >> On Sat, Mar 5, 2016 at 8:09 AM, Matthew Flatt <[email protected]> wrote: >> >> > At Thu, 03 Mar 2016 11:00:23 -0600, Vincent St-Amour wrote: >> >> >> On Wed, 02 Mar 2016 22:23:29 -0600, >> >> >> Matthew Flatt wrote: >> >> >> > Instead of using the existence of a source location to determine >> >> >> > where >> >> >> > to add instrumentation, debugging should be based on the details of >> >> >> > the >> >> >> > source location. I'm not immediately sure of the right rule, but I'll >> >> >> > work on it. >> >> >> >> >> >> Would `syntax-original?` help here? >> >> > >> >> > This is sort of job that `syntax-original?` was intended for, but I >> >> > think it doesn't work well. >> >> > >> >> > For example, if you have >> >> > >> >> > (define-syntax-rule (m x) >> >> > (* (+ x 1) 2)) >> >> > >> >> > and you use `m` in the same module, then you want an error for a >> >> > non-numeric `x` to highlight `(+ x 1)`. (Since `m` doesn't guard >> >> > against a bad `x`, it's probably not intended as an abstraction.) A >> >> > `syntax-original?` test would limit highlighting to the uses of `m`. >> >> > >> >> > I think this line of thought and other experience with >> >> > `syntax-original?` is why we haven't used it in errortrace. >> >> > >> >> > >> >> > One alternative is to make errortrace add a syntax property to the >> >> > original program, and then then only instrument forms that have the >> >> > syntax property after expansion. That implements a notion of >> >> > "original?" that includes templates in the source program, and it would >> >> > be consistent with the old use of source locations to determine >> >> > "original?". >> >> > >> >> > DrRacket compiles files with errortrace instrumentation to bytecode, >> >> > and that suggests preserving the syntax property in bytecode. We don't >> >> > yet have a mechanism for designating new syntax properties for >> >> > preservation in bytecode, but it was just a matter of time... >> >> > >> >> > I see a few possible approaches to preserving syntax properties: >> >> > >> >> > * Add a parameter that lists keys to be preserved. The parameter's >> >> > default value would be `(list 'paren-shape)`. >> >> > >> >> > This approach would probably work well enough for DrRacket and >> >> > errortrace, because DrRacket could set the parameter while writing >> >> > errortrace-instrumented bytecode. It's easy to imagine uses of >> >> > syntax properties where that kind of configuration from the outside >> >> > is inconvenient, though. >> >> > >> >> > * Introduce a naming convention for symbols as syntax properties. For >> >> > example, a symbol that starts with the letters "preserved:" could >> >> > mean that the property should be preserved in bytecode. >> >> > >> >> > A naming convention is easy, and it doesn't require cooperation from >> >> > the tool that's writing bytecode. We'd still have to declare >> >> > 'paren-shape to be a special case. >> >> > >> >> > * Introduce a prefab structure and a convention that a key is >> >> > preserved if it is an instance. For example, the designated prefab >> >> > structure type could be >> >> > >> >> > (struct preserved (name) #:prefab) >> >> > >> >> > and then '#s(preserved errortrace) as a syntax-property key would be >> >> > preserved. >> >> > >> >> > To make this work, syntax-property keys would have to be compared >> >> > with `equal?` instead of `eq?`, but I think that change would be ok. >> >> > >> >> > Among these options, I'm leaning toward the last one. >> >> > >> >> > Any other ideas? >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> "Racket Developers" group. >> >> > To unsubscribe from this group and stop receiving emails from it, send >> >> > an >> >> email to [email protected]. >> >> > To post to this group, send email to [email protected]. >> >> > To view this discussion on the web visit >> >> >> https://groups.google.com/d/msgid/racket-dev/56dae8b5.4e2b620a.62d8b.ffffc560SM >> >> TPIN_ADDED_MISSING%40gmr-mx.google.com. >> >> > For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To post to this group, send email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/56db5c48.e9a2420a.265b2.09b9SMTPIN >> _ADDED_MISSING%40gmr-mx.google.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/CAL3TdOPBtQr704xzcbWQjdE0R%2BjAnaN >> qUEpzrs6jEqFycqpckg%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/56db686f.8796420a.7fda6.186eSMTPIN_ADDED_MISSING%40gmr-mx.google.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdONgB-U1d%3DhEnt8fJzfT5-OnNeTrC0vpbkuuYsV1FmTPsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
