At Sat, 5 Mar 2016 17:20:55 -0600, Robby Findler wrote: > 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?
Yes. > 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. That's a good point. > 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-OnNeT > rC0vpbkuuYsV1FmTPsw%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/56db72b7.620e430a.59ed9.3862SMTPIN_ADDED_MISSING%40gmr-mx.google.com. For more options, visit https://groups.google.com/d/optout.
