What if #:authentic (or whatever) were only allowed on immutable
objects and we allowed them to be copied? Then contracts could protect
them.

Robby


On Thu, May 11, 2017 at 5:38 PM, Matthias Felleisen
<[email protected]> wrote:
>
> @ Christos
>
> #:authentic explicitly introduces a channel of communication that it is not 
> protectable by contracts. This makes Racket’s contract system explicitly 
> incomplete. It might have been incomplete in the past for other reasons.
>
> If the name isn’t fixed, #:no-proxy-allowed would be my preference.
>
> — Matthias
>
>
>
>
>
>> On May 11, 2017, at 12:48 PM, Scott Moore <[email protected]> wrote:
>>
>>> I agree that generally don't want performance declarations that
>>> interfere with reasonable interposition. The good uses of `#:authentic`
>>> would be in places where the struct representation of a value is not
>>> exposed or where the values themselves are not exposed (so any
>>> interposition means being on the "inside" where you can change the
>>> code, anyway).
>>
>> Yes, I agree with this. I think as far as how this changes Racket’s data 
>> abstraction model, the key is “where the values themselves are not exposed.”
>> #:authentic only has an interesting effect in the other case, where 
>> “outside” code gets its hands on a value of the struct type. Previously, I 
>> could write a program that used inspectors to impersonate this value 
>> regardless of the “inside” code’s intent. Now that would no longer be 
>> possible.
>>
>> I doubt there is much code that currently relies on being able to do this 
>> and so I would say go ahead. (Perhaps DrRacket or other debugging tools?)
>>
>> On the other hand, Spencer already asked if this would be something the 
>> optimization coach would recommend. I think it would be important for the 
>> documentation of #:authentic or the implementation of such a coach to stress 
>> the importance of the rules of thumb you just laid out.
>>
>> --
>> 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/3c430798-e93a-4900-8215-198f77d9b991%40Spark.
>> 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/D688771A-C477-40D8-B209-D9506362C5CB%40ccs.neu.edu.
> 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/CAL3TdOP%3DRD0EH4E3SQ39jbtks_saC2xW0gNr5VKja42MWFmkXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to