[racket] shared and immutable structures

The other David seemed to suggest he had an app where immutable cyclic
data was important. Maybe it would be useful to hear a few more
details to see if Matthew's reasoning holds up there?

Robby

On Tue, Feb 1, 2011 at 2:47 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Tue, 1 Feb 2011 12:38:44 -0800, David Herman wrote:
>> Just thinking out loud, but is there any way to use the unsafe operations to
>> make the shared library work for immutable data? If you can prove it's
>> actually safe, then there'd be no harm to users. (After all, as you say,
>> that's what it's doing with pairs.)
>
> The difference is that pairs are defined a priori as allowing the
> possibility of cycles, so you know that possibility exists when working
> with pairs.
>
> If my module gives yours a structure type, however, I may not want to
> automatically give yours the capability to create cyclic instances of
> the structure type. In that sense, creating a cycle is not always safe.
>
> Furthermore, implementing the cycle by creation plus mutation would
> mean introducing mutation for a supposedly immutable datatype, which
> isn't necessarily safe if the intermediate state is visible. Attempting
> to hide the intermediate state creates all sorts of new problems for
> features like properties and guards.
>
> Along those lines, granting the capability to create cyclic instances
> seems to be just about tantamount to granting mutability, so `shared'
> might as well require mutability.
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>