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
<ro...@eecs.northwestern.edu> 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
> <matth...@ccs.neu.edu> 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 <sdmo...@fas.harvard.edu> 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 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/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 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/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 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/CAL3TdONiMypw5RyQUN68Gqynu%2BkmGH6FvfyNbVoW8ec_1oXh3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to