• bearophile (60/61) Mar 01 2010 If you think the following idea is useful, then I can turn it into an en...
• bearophile (19/19) Mar 02 2010 In Java there are few uncommon situations where it's useful to put side ...

bearophile <bearophileHUGS lycos.com> writes:

If you think the following idea is useful, then I can turn it into an
enhancement request (or even a little DEP).

Many of the features that D adds to C seems to consist in statically verified
fences and walls that can be added to the flow of information across different
parts of a program state. So such parts can't change each other, hopefully
helping avoid some bugs.

Recently Michel Fortin has written:
What you really need is to have a const view of the global state. And this
could apply to all asserts too.<

Generally I'd like a program to behave in the same way in release and not
release mode (Bug 3856 too is related to this). So it can be nice if the type
system assures that asserts have only a const view of the program state.

This shows what I'd like to avoid:

import std.stdio: writeln;
bool test(ref int x) {
    x++;
    return true;
}
void main() {
    int x;
    writeln(x);
    assert(test(x));
    writeln(x); // prints 0 in release mode, 1 otherwise
}


To avoid that, according to Michel, it can be defined a  readonly attribute
that is transitive and is similar to  pure:


import std.stdio: writeln;
 readonly bool test(ref int x) {
    x++; // not allowed in a  readonly function
    return true;
}
void main() {
    int x;
    writeln(x);
    assert(test(x));
    writeln(x);
}


 readonly disallows writing global variables, and instance/static attributes,
but they can be read if visible. Local variables inside the function can be
written/created too as in  pure functions.

 pure functions are a subset of  readonly functions, so the type system has to
allow (code untested):

 pure int sqr1(int x) { return x * x; }
 readonly int sqr2(int x) { return x * x; }
void main() {
     readonly int function(int x)[] funcs = [&sqr1, &sqr2];
}

And it has to disallow:

 pure int sqr1(int x) { return x * x; }
 readonly int sqr2(int x) { return x * x; }
void main() {
     pure int function(int x)[] funcs = [&sqr1, &sqr2];
}


If the D language gains a little more reflectivity, that is a little more
read-only access to some of the metainformation the compiler has about the
code, then  readonly can even become an user-defined attribute defined in a
Phobos module, using only the D language itself (you have to import it to
compile the module). This is a way to extend a bit the D type system with D.

Maybe you can do that with a __traits that allows to know the global and local
names used inside a function plus if they are just read or read/written:

int y;
void foo(int x) {
  writeln(x);
  y++;  
}


foreach (name; __traits(getNamesUsedIn, "foo"))
  writefln(typeid(typeof(name)), " ", __traits(isWrittenIn, name, "foo"));

Prints:
int false
int true


Time ago I have shown something related, but here it uses a second language,
JavaScript, on C++ code:

http://lwn.net/Articles/370717/
https://developer.mozilla.org/En/Dehydra/Using_Dehydra

Maybe the  outer attribute I have discussed time ago too can be defined with
those getNamesUsedIn and isWrittenIn traits:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=106098

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

In Java there are few uncommon situations where it's useful to put side effects
inside asserts.

This Java code manipulates an array, and then wants to assert something about
this computation. To perform such tests it needs the old array, that has to be
copied. But in release mode the programmer doesn't want to perform such extra
array copy, so the array copy too is inside an assert:


void foo(final int[] array) {
    // Inner class that saves state and performs final consistency check
    class DataCopy {
        private int[] arrayCopy;
        DataCopy() { arrayCopy = (int[]) array.clone(); }
        boolean isConsistent() { return Arrays.equals(array, arrayCopy); }
    }

    DataCopy copy = null;

    // Always succeeds; has side effect of saving a copy of array
    assert ((copy = new DataCopy()) != null);

    ... // Manipulate array

    // Ensure array has same ints in same order as before manipulation.
    assert copy.isConsistent();
} 


In D code I prefer to solve this problem with a debug{/*array copy*/}, and keep
my asserts side-effects free.

Bye,
bearophile