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 <stamo...@eecs.northwestern.edu> 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 <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/CAL3TdON7cm1CuKEy9AshbhBonLQ%2BL1-duxGbWiX%2Bv6RLx_B8hA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
