[erlang-questions] Re: Shared/Hybrid Heap

[Paulo Sérgio Almeida]

Hi Robert,

there is a point on which I do not agree; when you say:

On 11/4/10 10:46 AM, Robert Virding wrote:

> - I think that having immutable data even within only one process is a big win. Having mutable data gives you all the problems of global data. Immutable data makes it much easier to keep track of what is happening with your data, which is always a Big Win.

I would say that having mutable data gives us SOME problems, but much 
LESS than when we have global mutable data.

You are mixing the problems due to:

- global data
- mutable data

In most languages around we have the nightmare of mutable global data, 
and the nasty problem of aliasing in object references.

On the other hand in Erlang we have processes that give us locality, but 
only immutable data in each process.

I (and others) think there is a place for a middle-ground where 
processes give us locality, allowing a divid-and-conquer of the global 
problem into simple parts, where the data in a given process is 
manageable, but where if the algorithm calls for mutable data then we 
should be able to use it. All the nasty problems of shared memory 
concurrency (from the programmer's point of view) have already 
disappeared when we have only per-process mutable data as opposed to 
global mutable data.

If the data is immutable and only pure functions are used, we have extra 
benefits, but not always can we afford it, nor is it necessary even for 
proving correctness. Lot's of classic formal methods stuff with 
pre-conditions, post-conditions, invariants, Hoare logic, etc, were made 
for the mutable data world. They become difficult to apply when we have 
global data and aliasing, but may well be applied when we have just a 
little local data.

The idea would be to be able to use the many proven algorithms that were 
created for the imperative sequential world inside each process, and let 
the process concept a la Erlang deal with the concurrency aspects.

I am not saying it is now practical to add it to Erlang, but that some 
language in this design spot (actors + local mutable data) makes much sense.

Regards,
Paulo