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

[Jonathan Amsterdam]

On Jan 30, 2008 4:40 AM, Mikael Pettersson <mikpe@REDACTED> wrote:
>
> 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.

Yes. I was just giving an interesting example of "destructive updates
under the covers."

> 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).

I disagree. You tell people that the function in the promise must be
idempotent or the results are undefined. The spec would say something
like, the implementation makes a best effort to run the function at
most once, but that is not guaranteed. Contrast with the case of
updatable cells, where as you pointed out, there is no way to
reconcile the semantics of updating with that of copying.

> (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.)

But it is fun to dream.