[erlang-questions] effect of destructive updates on GC implementation

[Mikael Pettersson]

Jonathan Amsterdam writes:
 > > Yes. I would much rather see a development where higher-order
 > > constructs can be optimized to either use destructive updates
 > > under the covers, or even transformations like e.g. removing
 > > unnecessary reverse() calls, or whatever. (*)
 > 
 > How about promises with memoization? That is, a no-argument fun whose
 > result is cached the first time it is called. This would let you
 > implement lazy lists, and get the performance bounds of the Okasaki
 > data structures. E.g. queues with worst-case (not amortized) O(1)
 > behavior.

In the context of this thread (GC in the presence of destructive
updates), memoization solves no problems. By the time the thunk
is forced, the thunk may have migrated to an older generation,
and the memoization part (making the thunk refer to the value)
may create a wrong-way pointer, just as ordinary updates can.

Furthermore, sending thunks between processes raises semantic
issues similar to the ones raised for other mutable data, only
worse because forcing a thunk also involves running code that
can have "normal" side-effects (I/O, ets, send/receive, etc).

(These features could be supportable had they been present in
Erlang from day one. But it's too late now. Scheme + threads
might be what you/we want.)