[Grace-core] Immutability in Grace

[Michael Homer]

On Sun, May 18, 2014 at 5:56 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
>> > Ok yep. In general I prefer the idea of annotations to new language constructs.
>> > I can see how defs could be used in immutable objects - but surely not vars?
>>
>> Since def/var represent the mutability of the reference, the "is immutable" annotation would apply to the referred data. Then it would be valid to have a "var x is immutable" point to immutable objects, as long as that "var" was not itself within an immutable scope.
>
> so again, I don't think this should be an annotation on the var or def declaration itself - perhaps on the type of the declaration
>
> var x :  Foo is immutable
That is an annotation on the var declaration itself.
>> As far as I can tell, neither approach would be able to make any deductions about the purity code without the help of the user, since there is no simple way of knowing (especially with the foreign C modules) whether data will be modified or not.
C code is always going to be able to do what it likes, so there's no
use worrying about it. If it breaks things then it's what's broken.
>> On another note, I think it be possible to solve the problem that Michael brought up by further restricting the definition of pure methods to "referentially transparent". The issue regarding inheritance, as far as I understand it, would disappear as that code would simply not be allowed.
>
> certainly the inheritance issue can go away like that.
> other ones, I'm not so sure.  I'm not sure what you mean precisely by "referentially transparent"
> (especially as its in quote marks) --- does not read *any* mutable state, perhaps?
> (which is subtly different to conditions like "does not read my mutable state, or
> does not read or write any mutable state :-)
Memoised code is referentially transparent but both reads and writes
mutable state. Is that to be permitted? Is there a way to permit it if
it isn't by default?
>> I do not think it would be too problematic a restriction, because objects that need to travel could then be structured in a "data object"/"IO wrapper object" way.
>>
>> method makeDataObject {
>>   object {
>>     // I am immutable
>>     def x = 1
>>     method size { x } // Referentially transparent
>>     // post(otherThread, self) - not referentially transparent, not allowed
>>   }
>> }
>>
>> method makeDataObject2 {
>>   object {
>>     // I am immutable
>>     inherits makeDataObject
>>     def y = 2
>>     method size { y } // Referentially transparent
>>   }
>> }
>>
>> method makeIOObject(dataObject) {
>>   object {
>>     // Not immutable anymore
>>     post(otherThread, dataObject) // Safe
>>   }
>> }
>>
>> Since the IO wrapper does not directly depend on the data, it can just be re-wrapped around the dataObject by the other thread on arrival to access its functionality. Of course, the wrapper will only have read-only access to the data, so any impure method operating on the fields of the dataObject will need to make a copy.
>
> sure. ugly but sure.
The question then is whether travelling objects need to be able to be
registered or not. You can probably work around the other cases you
might want other code in them, but not that.
-Michael