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.
