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.ffffc560SMTPIN_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/CAL3TdOMsxLJ4u5ivtLKXe0e9hy7e%3DkwY8DN_YMqPhCGNMP7yAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
