www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pure and Structs

reply dsimcha <dsimcha yahoo.com> writes:
I'm trying to annotate some code with pure and nothrow (mostly just to test it
out and give feedback at this point), and I've noticed one very irritating
thing.  If I use a struct as follows:

struct LameStruct {
    uint foo;
    uint bar;

    void doStuff() {
        foo++;
        bar++;
    }
}

void foo() {
    LameStruct lamestruct;
    s.doStuff();
}

foo() cannot be annotated as pure in this case because technically, it calls
doStuff(), which modifies lamestruct.  However, I think in this fairly simple
case, DMD could reasonably figure out that this function is still
referentially transparent and safe for multithreading, at least if LameStruct
is defined in the same module as foo().  Of course, no other function can have
access to lamestruct before foo() is called because it is created within
foo().  Furthermore, doStuff() only modifies value types that it owns, and the
return type is void.

Will pure eventually be expanded to deal with more cases where the referential
transparency and inherent thread-safety of a function is obvious to humans,
like these, or is this simply asking too much?
Dec 26 2008
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article

 I'm trying to annotate some code with pure and nothrow (mostly just to test it
 out and give feedback at this point), and I've noticed one very irritating
 thing.  If I use a struct as follows:
 struct LameStruct {
     uint foo;
     uint bar;
     void doStuff() {
         foo++;
         bar++;
     }
 }
 void foo() {
     LameStruct lamestruct;
     s.doStuff();
 }
 foo() cannot be annotated as pure in this case because technically, it calls
 doStuff(), which modifies lamestruct.  However, I think in this fairly simple
 case, DMD could reasonably figure out that this function is still
 referentially transparent and safe for multithreading, at least if LameStruct
 is defined in the same module as foo().  Of course, no other function can have
 access to lamestruct before foo() is called because it is created within
 foo().  Furthermore, doStuff() only modifies value types that it owns, and the
 return type is void.
 Will pure eventually be expanded to deal with more cases where the referential
 transparency and inherent thread-safety of a function is obvious to humans,
 like these, or is this simply asking too much?


Oh, and I just realize my silly mistake and I apologize.  Of course nobody
writes
referentially transparent functions that return void.  Please pretend foo()
returns something that would be consistent with it being pure.
Dec 26 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Will pure eventually be expanded to deal with more cases where the referential
 transparency and inherent thread-safety of a function is obvious to humans,
 like these, or is this simply asking too much?


If it can be proven (and it can in your example) it can be pure.
Dec 26 2008
parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Walter Bright wrote:

 dsimcha wrote:

 Will pure eventually be expanded to deal with more cases where the
 referential
 transparency and inherent thread-safety of a function is obvious to
 humans,
 like these, or is this simply asking too much?


 
 If it can be proven (and it can in your example) it can be pure.


I'm curious, how difficult is it to mechanically prove/disprove purity
in the general case?

I thought this was going to be one of those things like escape analysis,
where we'd have to settle for a subset of the provable cases for the
sake of easy of implementation.
Dec 27 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Chad J wrote:

 Walter Bright wrote:

 dsimcha wrote:

 Will pure eventually be expanded to deal with more cases where the
 referential
 transparency and inherent thread-safety of a function is obvious to
 humans,
 like these, or is this simply asking too much?


 If it can be proven (and it can in your example) it can be pure.


 
 I'm curious, how difficult is it to mechanically prove/disprove purity
 in the general case?


I don't know.



 I thought this was going to be one of those things like escape analysis,
 where we'd have to settle for a subset of the provable cases for the
 sake of easy of implementation.
Dec 27 2008