Isolates, Identity and Immutability

namgk / ambienttalk

Automatically exported from code.google.com/p/ambienttalk

0 stars 0 forks source link

I believe "def" should define constant bindings between names and values. This 
would require a 
new keyword "var" (as in E) for distinguishing constant from variable bindings. 
Almost all of the 
definitions in AT are conceptually constant, yet we cannot take advantage of 
this fact because 
there *might* always be an assignment.

Being able to derive that an object is constant has advantages. Take isolates, 
for example. The 
lexical scoping restriction on isolates is sometimes really annoying. It would 
seem nicer to be 
able to define pass-by-copy based on mutability: e.g. immutable objects are 
pass by copy, 
mutable ones are pass by ref. Isolates could then access their lexical scope 
but only if the 
accessed vars are themselves immutable. A pbc object is copied together with 
its lexically free 
variables.

Another example: in Newspeak, Bracha requires namespace objects to be 
immutable. I haven't 
figured out yet what the advantages are in the context of NS.

Note that changing the semantics of "def" may not be enough to achieve "deep" 
immutability of 
objects. Tables, for example, are also mostly immutable. So perhaps, like in E, 
the syntax "[...]" 
should create immutable objects that can be used (if necessary) to spawn a 
mutable copy 
instead.

Original issue reported on code.google.com by tvcut...@gmail.com on 16 Sep 2008 at 3:13

Another issue with isolates currently is that they use the default identity-semantics for ==. Usually, however, it is more meaningful to define equality in terms of the structure of isolates, rather than in terms of their identity (since they are copied a lot and copying changes identity, but not structure). There seems to be a relationship between at first unrelated concepts: - mutability: immutable vs deeply immutable vs mutable - equality: equal-by-id vs equal-by-value, i.e. are 2 objects equal based on identity or their values? - allocation: stack-allocation vs heap-allocation - parameter-passing: pass-by-copy vs pass-by-reference These seem to define a wide spectrum, e.g.: - numbers are immutable, equal-by-value, can be stack-allocated (in C and Java, at least) and are therefore usually pass-by-copy. - objects can be mutable, are usually equal-by-id, are usually heap-allocated and therefore passed by reference. Isolates are pass-by-copy objects, but they do not 'fix' the mutability and equality dimensions. Therefore, these dimensions may interfere.

namgk / ambienttalk

Isolates, Identity and Immutability #25