[erlang-questions] Re: Shared/Hybrid Heap

[Robert Virding]

Hi Paulo,

I was referring more here to global *within* a process, not between processes. Sorry for being unclear. If you allow mutable data within a process then it will necessarily be global within that process. Even if I have to pass a reference to it I will still have no control over who or when it mutated. Things can happen under my feet without my knowing about it. This is the same problem as for sequential languages which have mutable data.

Allowing non-sharing between processes would lessen some of the problems, but not wholly remove them.

Also smart garbage collection is easier if you have immutable data. I know this is an implementation detail, but immutable data makes the garbage collector simpler and more efficient, you can do smart things if you know data does not change.

Robert

----- "Paulo Sérgio Almeida" <psa@REDACTED> wrote:

> 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