digitalmars.D - newby: transitive const, I like the idea
- Fawzi Mohamed (45/45) Apr 03 2008 I am new to D and I wondered if I should weight in the seemingly very
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
Apr 03 2008