errortrace insrumentation (was: [racket-users] Racket 6.4 very slow)

[Matthew Flatt]

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?

[Robby Findler]

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

> --
> 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+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> 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.

[Matthew Flatt]

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.

[Robby Findler]

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

> 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.

[Matthew Flatt]

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.

> https://groups.google.com/d/msgid/racket-dev/CAL3TdOPBtQr704xzcbWQjdE0R%2BjAnaN
> qUEpzrs6jEqFycqpckg%40mail.gmail.com.

[Vincent St-Amour]

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

> 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.

[Robby Findler]

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?

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.

It does feel more "natural" in a sense, tho. But perhaps that is not
to be trusted.

Robby

> 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.

[Robby Findler]

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

[Vincent St-Amour]

Right, I understand that.

Are any syntax properties used as heavily as source locations, though?

Vincent

[Matthew Flatt]

As a concrete example, I think 'origin tracking should be ephemeral.
Why would an 'origin property end up on quoted syntax? I'm not entirely
sure, but I tried adding check on bytecode writing for a fresh `raco
setup`, and it apparently happens, even in the bootstrapping phase.

[Matthew Flatt]

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.

> https://groups.google.com/d/msgid/racket-dev/CAL3TdONgB-U1d%3DhEnt8fJzfT5-OnNeT
> rC0vpbkuuYsV1FmTPsw%40mail.gmail.com.

[Robby Findler]

Right: it's the known unknowns that I'm worried about :)

On Sat, Mar 5, 2016 at 5:29 PM, Vincent St-Amour

[Stephen Chang]

> 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?

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdOOU9Oa8V5bjxdtbTUWAezegHso85ity4tTcte-%2BSVoCmA%40mail.gmail.com.