Out of curiosity, where does the additional overhead come from? Without looking 
at the struct predicate code, I would have expected this to be a 
relatively-well predicted branch on the Scheme_Type of the object. I haven’t 
been following the Chez port though—are impersonators being implemented at a 
higher level of abstraction?

That aside, I don’t think there is too much lost from doing this—as you 
mention, it was already possible to create structs that could not be easily 
impersonated.
There are some edge cases this would change though, where you use the program 
structure to make sure you have the right inspector around. For something like 
the expander, that’s probably not an issue, as the expander will be running 
before the program has a chance to intervene.

I think the main danger would be if it was abused for the performance benefit 
in libraries where a client might reasonably want to interpose...

On May 11, 2017, 11:16 AM -0400, Matthew Flatt <mfl...@cs.utah.edu>, wrote:
> There are many structure types that are private to some library (such
> as the expander) and will never have impersonators. The compiler can't
> know that, though, and the possibility of an impersonator means that
> the structure type's predicate has to be twice as expensive. Field
> selection is also more expensive in certain cases. I'm not sure about
> the current Racket VM, but the cost is measurable when running the
> Racket expander on Chez Scheme.
>
> So, I'm thinking of adding a `prop:authentic` structure type property
> --- with an `#:authentic` shorthand for `struct` --- that prevents
> instances of a structure type from being impersonated or chaperoned.
> Naturally, an authentic structure type's supertype and subtypes must
> also be authentic.
>
> Any opinions?
>
> --
> 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/59148060.14da620a.a334b.158bSMTPIN_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/244c97c3-b773-4e6f-92b7-1f06414aaa74%40Spark.
For more options, visit https://groups.google.com/d/optout.

Reply via email to