> 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 very recently wanted this and almost tried to hijack 'paren-shape so I'm happy to see this thread. I think ephemeral-by-default is the proper choice. There's no reason to unnecessarily add to the size of zos, in addition to the other stated reasons. > an optional argument when setting a property to indicate whether the setting > is ephemeral. I think this is the best interface from a user perspective, though internally the compiler would still have to implement one of the original options right? On Sat, Mar 5, 2016 at 7:18 PM, Robby Findler <[email protected]> wrote: > Right: it's the known unknowns that I'm worried about :) > > On Sat, Mar 5, 2016 at 5:29 PM, Vincent St-Amour > <[email protected]> wrote: >> Right, I understand that. >> >> Are any syntax properties used as heavily as source locations, though? >> >> Vincent >> >> >> >> On Sat, 05 Mar 2016 17:23:01 -0600, >> Robby Findler wrote: >>> >>> Our experience with the source location change suggests that there are >>> many places where code is implicitly relying on syntax properties not >>> being preserved in byte code. This entire thread is inspired by one >>> such (errortrace performance), and I know that I fixed several >>> lingering bugs like this in redex well after the initial change. >>> (Those bugs manifested as poor source location reporting for errors in >>> redex programs). That experience makes me think we should not preserve >>> all properties. (I don't have a sense of what the performance costs >>> would be, but we could measure that if we cared, I think.) >>> >>> Robby >>> >>> >>> On Sat, Mar 5, 2016 at 5:16 PM, Vincent St-Amour >>> <[email protected]> wrote: >>> > What would be use cases for ephemeral properties? >>> > >>> > I agree that most properties wouldn't need to be preserved, but I can't >>> > think of a case where we would want to explicitly not have a property be >>> > preserved. >>> > >>> > That, and having two kinds of syntax properties would be potentially >>> > confusing. Your third solution does make the distinction pretty clear, >>> > but having a single kind would make the interface simpler. >>> > >>> > Vincent >>> > >>> > >>> > On Sat, 05 Mar 2016 16:23:00 -0600, >>> > Matthew Flatt 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/CAL3TdOOU9Oa8V5bjxdtbTUWAezegHso85ity4tTcte-%2BSVoCmA%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/CAFfiA1%2BnYpOfap0HFjvCmu%2BbL_DZ0r4LkLJ_b95swaqSGas29Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
