Yes except that you can contract cons cells. So why couldn’t you contract 
authentic structs then? 



> On May 11, 2017, at 6:41 PM, Robby Findler <[email protected]> 
> wrote:
> 
> Indeed: if we did that, then these structs would be much like cons
> cells currently are.
> 
> Robby
> 
> 
> On Thu, May 11, 2017 at 5:39 PM, Robby Findler
> <[email protected]> wrote:
>> 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/1AFE0571-C48C-4B22-B445-D96B283C6885%40ccs.neu.edu.
For more options, visit https://groups.google.com/d/optout.

Reply via email to