D const design rationale

[eao197]

On Sat, 23 Jun 2007 20:44:41 +0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Reiner Pope wrote:
>> You mention functional programming a fair bit with respect to const,  
>> which is nice to hear. But nothing in the current const system allows  
>> you to declare a verifiably 'pure' function; can we expect some  
>> annotation for functions which says 'this function doesn't read/write  
>> any global variables?'
>
> You're right, we're moving in the right direction, but we're not there  
> yet.

Here is an interesting quote from Joe Armstrong dissertation "Making  
reliable distributed systems in the presence of software errors" [1] (I  
highlight most important fragments by **):

<quote>
In the above table the code has been subject to a simple analysis which
superficially classifies each module or function as “clean” or “dirty.” A
module is considered dirty if any function in the module is dirty,  
otherwise
it is clean. To simplify matters I say that a function is dirty if it  
sends or
receives a message or if it calls one of the following Erlang BIFs:
...
The reason for this classification is that any code fragment which calls
one of these BIFs is potentially dangerous.

**Notice that I have chosen a particularly simple definition of “dirty.”**  
At
first sight it might appear that it would be better to recursively define a
module as being dirty if any function in the module calls a “dangerous”
BIF or a dirty function in another module. Unfortunately with such a
definition virtually every module in the system would be classified as  
dirty.

The reason for this is that if you compute the transitive closure of all
functions calls exported from a particular module, **the transitive closure
will include virtually every module in the system**. The reason why the
transitive closure is so large is due to “leakage” which occurs from many
of the modules in the Erlang libraries.

**We take the simplifying view** that all modules are well-written and
tested, and that if they do contain side-effects, that the module has been
written in such a way so that the side effects do not leak out from the
module to adversely affect code which calls the module.
</quote>
$8.3, p.171.

Armstrong said that about the AX301 software -- more the 1.1 millions of  
Erlang code (this is one of the biggest FP software in the world). But  
even in pure functional Erlang there isn't special marks for 'pure/clean'  
or 'impure/dirty' functions. Because it can lead to that almost all  
modules in a system would be 'dirty'.

Adding 'pure' modificator to D can lead, IMHO, to the following  
alternatives:
1) nobody would use 'pure' at top level of modules/libraries/frameworks,  
because any top-level function/method would use some 'impure' function  
inside, or
2) it is necessary to introduce some constructs into language to define  
'logical pureness' -- function will be marked as pure, but can use impure  
calls inside. Like 'mutable' keyword in C++ used for 'logical  
constantness'.

[1] http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

-- 
Regards,
Yauheni Akhotnikau