"Janice Caron" wrote in message
> It hardly needs a detailed explanation. In fact it's trivial to understand. Watch:
>
>    // in C++
>    void f(const C &c)
>    {
>        c.some.deeply.nested.but.reachable.var++;
>    }
>
> In a multithreaded program, a thread switch may occur between the read and the write of the read/write cycle that is ++. If that happens, you're screwed.
>
>    // in D
>    void f(const C c)
>    {
>        c.some.deeply.nested.but.reachable.var++; /*ERROR*/
>    }
>
> In D, such dodgy code just won't compile.

int x;

struct Var
{
    const int opPostInc()
    {
        return x++;
    }

    // when it is supported
    // int opImplicitCast() { return x; }
}

struct Reachable
{
    Var var;
}

struct But
{
    Reachable reachable;
}

struct Nested
{
    But but;
}

struct Deeply
{
    Nested nested;
}

struct Some
{
    Deeply deeply;
}

class C
{
    Some some;
}

void f(const C c)
{
    c.some.deeply.nested.but.reachable.var++; // OK (compiled with D2)
}

Notice that the Var sturct is semantically equivalent to an int data member (or will be, at least, when opImplicit cast works).

The point is that logical const is still possible, even with transitive const, because the global namespace is not const.  There is no way around this except with pure functions.  Which I think you agree.

HOWEVER, the point that everyone is arguing is why does logical const make pure functions or functional programming impossible?  Clearly, it is ALREADY POSSIBLE to have logical const, and clearly, pure functions are possible! I'm saying transitive const is mathematically equivalent to logical const ALREADY.  Please try and grasp that concept.

-Steve

"Walter Bright" wrote
> Bill Baxter wrote:
>> If the ultimate goal is support for multiprogramming, then shouldn't the detailed design work should start *there*, with how to do great multiprogramming?  Rather than with const.
>>
>> Not saying that you guys have done this, but I know from my own experience doing research that it's easy to get hung up trying to solve a tough but solvable problem that seems relevant for getting from A to B, only to realize in the end that it was not as relevant as I thought.
>
> I think it is fairly obvious that transitive invariant (and const) is key to multiprogramming. The transitive closure of the state of everything reachable through an object is part of the state of that object, and all the troubles with multiprogramming stem from the state of an object changing asynchronously.

I think it's not so fairly obvious but true that transitive invariant and const are equivalent to logical invariant or const.  Please re-read my original example for the proof.

This puts a big dent in your argument that logical const doesn't cut it for multiprogramming, because what we have now is a logical const system.

-Steve

"Janice Caron" wrote
> pure requires transitive const.

Forgive me if I don't take your word for it.  Please prove this. Specifically, why pure fails with logical const (not head const as C++ is). Assume these are the rules for pure:

- a pure function can only access local variables
- all parameters to a pure function must be logically invariant
- a pure function can only call pure functions or methods.
- a pure method cannot access the mutable portion of a logically invariant
data value.

-Steve

On 02/04/2008, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>  HOWEVER, the point that everyone is arguing is why does logical const make
>  pure functions or functional programming impossible?

I thought I'd covered that, but no matter. I'll try again.

Logical const in mutually incompatible with transitive const. No object can be simultaneously both fully transitive and have reachable mutable fields. It's just impossible. (Here I define "reachable" as meaning "

  Clearly, it is ALREADY
>  POSSIBLE to have logical const, and clearly, pure functions are possible!
>  I'm saying transitive const is mathematically equivalent to logical const
>  ALREADY.  Please try and grasp that concept.
>
>  -Steve
>
>
>

Bugger! That last post got sent before I'd finished writing it.

>     c.some.deeply.nested.but.reachable.var++; // OK (compiled with D2)

Overriding "opPostInc() const" doesn't prove anything. If you want to make a serious point, just call you function f or foo or something. Using operator overloads to disguise what's going on doesn't make /anything/ clearer.


>  The point is that logical const is still possible, even with transitive
>  const, because the global namespace is not const.

It seems you and I disagree about the meaning of the phrase "logical const". The ability to manipulate global variables does not constitute logical constancy in my book.


>  HOWEVER, the point that everyone is arguing is why does logical const make
>  pure functions or functional programming impossible?  Clearly, it is ALREADY
>  POSSIBLE to have logical const

We are suffering from a communications difficulty caused by you and I using the same phrase ("logical const") to mean entirely different things. Unless we can agree on a common terminology, we're not going to be able to get anywhere with this discussion.

On 02/04/2008, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> "Janice Caron" wrote
>  > pure requires transitive const.
>
>  Forgive me if I don't take your word for it.  Please prove this.
>  Specifically, why pure fails with logical const (not head const as C++ is).

    class Stupid
    {
        int x;
        mutable int y;
    }

    not_pure void f(const(Stupid) stupid) const
    {
        int t = y;
        ++t;
        y = t;
    }

Try calling f from two threads at the same time, imagine a thread switch partway through f.

"Janice Caron" wrote
> On 02/04/2008, Steven Schveighoffer wrote:
>> "Janice Caron" wrote
>>  > pure requires transitive const.
>>
>>  Forgive me if I don't take your word for it.  Please prove this.
>>  Specifically, why pure fails with logical const (not head const as C++
>> is).
>
>    class Stupid
>    {
>        int x;
>        mutable int y;
>    }
>
>    not_pure void f(const(Stupid) stupid) const
>    {
>        int t = y;
>        ++t;
>        y = t;
>    }
>
> Try calling f from two threads at the same time, imagine a thread switch partway through f.

I'm assuming you meant f to be part of Stupid?  And that not_pure means that you are trying to make f pure, but this is your comment that it doesn't work?

This would not compile under the rules I specified.  Note the rules:

- a pure function can only access local variables (I'm going to ammend this
to say local variables and globally invariant variables).
- all parameters to a pure function must be logically invariant
- a pure function can only call pure functions or methods.
- a pure method cannot access the mutable portion of a logically invariant
data value.

Your code violates rules 2 and 4.

-Steve

"Janice Caron" wrote
> Bugger! That last post got sent before I'd finished writing it.
>
>>     c.some.deeply.nested.but.reachable.var++; // OK (compiled with D2)
>
> Overriding "opPostInc() const" doesn't prove anything. If you want to make a serious point, just call you function f or foo or something. Using operator overloads to disguise what's going on doesn't make /anything/ clearer.

You are missing the point.  x is part of the class state, because it is accessible through var.  It is a mutable part of the const class state because it resides in global (non-const) space.  You have to think outside the box.

>>  The point is that logical const is still possible, even with transitive
>>  const, because the global namespace is not const.
>
> It seems you and I disagree about the meaning of the phrase "logical const". The ability to manipulate global variables does not constitute logical constancy in my book.

The ability to use global mutable variables as part of the class state is the point.

>>  HOWEVER, the point that everyone is arguing is why does logical const
>> make
>>  pure functions or functional programming impossible?  Clearly, it is
>> ALREADY
>>  POSSIBLE to have logical const
>
> We are suffering from a communications difficulty caused by you and I using the same phrase ("logical const") to mean entirely different things. Unless we can agree on a common terminology, we're not going to be able to get anywhere with this discussion.

The communications gap is not in that I do not understand what logical const is.  The communications gap is that you are not understanding that what I have posted is semantically equivalent to logical const.  What I am showing is that transitive const is the same as logical const because you can use the always mutable global state as part of the class state.  What this translates to is that logical const is sufficient for multi-programming as long as the correct rules are chosen.

What I am asking is, because semantically logical const is possible, why is actual logical const not allowed?

-Steve

On Wed, 02 Apr 2008 16:04:36 +0200, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> - a pure method cannot access the mutable portion of a logically invariant data value.

Wouldn't this basically make it transitive invariant?

"Simen Kjaeraas" wrote
> On Wed, 02 Apr 2008 16:04:36 +0200, Steven Schveighoffer  wrote:
>
>> - a pure method cannot access the mutable portion of a logically invariant data value.
>
> Wouldn't this basically make it transitive invariant?

Yes, which makes my point :)  pure must be transitive, but const / invariant by itself does not need to be.

-Steve