[racket] shared and immutable structures

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue Feb 1 16:02:08 EST 2011

Implicitly here, you seem to be saying you're fine tossing that kind
of reasoning for lists. Are you?


On Tue, Feb 1, 2011 at 2:58 PM, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
> I am with Matthew. Immutable structs -- other than historically 'blessed' ones -- give you inductive reasoning. If you allow cycles anyway, that's out the window.
> On Feb 1, 2011, at 3:47 PM, Matthew Flatt 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
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users

Posted on the users mailing list.