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 <mfl...@cs.utah.edu> 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 <mfl...@cs.utah.edu> 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 <mfl...@cs.utah.edu> > >> >> 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 racket-dev+unsubscr...@googlegroups.com. > >> >> > To post to this group, send email to racket-dev@googlegroups.com. > >> >> > 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 racket-dev+unsubscr...@googlegroups.com. > >> > To post to this group, send email to racket-dev@googlegroups.com. > >> > 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 racket-dev+unsubscr...@googlegroups.com. > >> To post to this group, send email to racket-dev@googlegroups.com. > >> 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 racket-dev+unsubscr...@googlegroups.com. > > To post to this group, send email to racket-dev@googlegroups.com. > > 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 racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-dev@googlegroups.com. > 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 racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. 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.
