newby: transitive const, I like the idea

[Fawzi Mohamed]

I am new to D and I wondered if I should weight in the seemingly very 
long and heated discussion on const, that maybe should die off.
After reading a while I decided to tell my opinion all the same.

I like the transitive const/invariant idea very much, and I think that 
something like it has to be introduced to make parallel functional 
stile possible.
Maybe I should also add that I do write multithreaded and parallel 
programs, so I care about these issues now.

Anyway I wanted to say that if one wants just functional style a weaker 
form of invariance is sufficient: a monotonic or signle assignement 
property is enough.
For example one could allow:

1) a special pointer that can have also a "frozen" value that is 
actually a pure delegate that can (and will) calculate the value upon 
request (it is important that the presence of the delegate should be 
invisible, i.e. one should not be able to know if a delegate is there 
or a value, only to get the value (which might need the evaluation of 
the delegate).

this would allow coping of the structure to another process with only a 
loss in efficency

or even
2) a special pointer that can have also an undefined value that is 
invisible from the outside, which means that the undefined falue cannot 
be read but blocks until the pointer has been assigned.
A second assigment to the pointer would be allowed only if it assign 
the same value (one can allow unifiable values, but now for simplicity 
I do not explain it).

this would allow the coping of a structure with undefined pointers to a 
process only if gets synchronized (unified/copied) periodically.

These things allow a lazy and parallel evaluation but do not introduce 
any indeterminsm (the single assignement variables are for example used 
in Mozart/Oz and described by van Roy and Haridi in Concepts Techniques 
and Models of Computer Programming).

So two weaker forms of const that might be worth exploring. Anyway I 
think that something like this needed, and now I am thinking about 
moving my work from D 1.0 (with which I started because I want to work 
with the language, not on the language) to D 2.0.

Another point that I wanted to make is that functional programming 
(that I like very much) is not atomatically parallel, in fact its most 
used structure, the list, is *extremly* sequential and likewise self 
recursion is *very* sequential, in a way that might be even more 
difficult for the compiler to remove.
On the other hand purity does indeed allow for many very nice high 
level optimizations.

Fawzi