"Lionello Lunesu" <lionello lunesu.remove.com> writes:

After reading Walter's posts these last weeks and Andrei's PDF, I think the 
D 2.0 invariant/const make a lot of sense, and I can see the how it opens up 
new possibilities.

I was a bit worried for a performance penalty because of the need for 
"idup"s, but then I realized that you only .idup when you use "invariant()" 
when you actually don't care about it being invariant or not. So converting 
all D 1.0 "char[]" to D 2.0 "string" might not be such a good idea.

One thing that I like is that suddenly C++ "const &" construction can be 
standardized and made safe at the same time! Because of invariant, "in" can 
safely pass the arguments by ref, instead of by value.

Sorry for repeating what most probably already know, but it just felt like a 
revelation that I had to share :-)  A bit slow perhaps, but I'm pretty sure 
I'm not the last one to /get it/.

Thanks Walter, Andrei for explaining this invariant/const thing over and 
over again, in different forms.

Now I'll have to change Phobos 2.0 to get "foreach(string s; new 
BufferedFile(..))" working ;-)

L.

Jason House <jason.james.house gmail.com> writes:

They say the best way to learn is to explain to someone else... 

Many have said FP style multithreading requires pure functions with invariant
data. The strange thing is that pure functions can't call invariant member
functions of their invariant data. Why would that be? That's especially strange
when the justification for invariant is multithreading.

I've been arguing for a while that mutable access to globals is like head const
and kills most of the benefits from the const system. Please help me understand
why I am wrong.

Lionello Lunesu Wrote:

 After reading Walter's posts these last weeks and Andrei's PDF, I think the 
 D 2.0 invariant/const make a lot of sense, and I can see the how it opens up 
 new possibilities.
 
 I was a bit worried for a performance penalty because of the need for 
 "idup"s, but then I realized that you only .idup when you use "invariant()" 
 when you actually don't care about it being invariant or not. So converting 
 all D 1.0 "char[]" to D 2.0 "string" might not be such a good idea.
 
 One thing that I like is that suddenly C++ "const &" construction can be 
 standardized and made safe at the same time! Because of invariant, "in" can 
 safely pass the arguments by ref, instead of by value.
 
 Sorry for repeating what most probably already know, but it just felt like a 
 revelation that I had to share :-)  A bit slow perhaps, but I'm pretty sure 
 I'm not the last one to /get it/.
 
 Thanks Walter, Andrei for explaining this invariant/const thing over and 
 over again, in different forms.
 
 Now I'll have to change Phobos 2.0 to get "foreach(string s; new 
 BufferedFile(..))" working ;-)
 
 L.
 
 

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
 The strange thing is that pure functions can't call invariant member functions
of their invariant data.

I don't think that's correct.

    class C
    {
        int x;

        int f() invariant pure
        {
            return x;
        }
    }

    invariant c = cast(invariant) new C;
    int n = c.f();

Should work just fine. Of course, the explicit cast necessary to
create an invariant C in the first place is a bit ugly. Maybe we need
"inew" to make new invariant objects?

Remember, a member function is nothing more nor less than a global
function with a hidden parameter and some name mangling. That means
that the rules for purity of member functions are identical to those
of global functions. You just have to insist that "this" be invariant.

Jason House <jason.james.house gmail.com> writes:

Janice Caron Wrote:

 On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
 The strange thing is that pure functions can't call invariant member functions
of their invariant data.

 
 I don't think that's correct.
 
 [example showing misinterpretation of what I'm talking about]

Consider this example:

class D{
  void invMemberFunc() invariant; // not pure
}

class C{
  int f(invariant D) invariant pure{
    D.invMemberFunc(); // illegal
  }
}

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
  Consider this example:
 <snip>

Oh well, that's obvious. f() can't call D.invMemberFunc() because
D.invMemberFunc() isn't pure. Pure functions can only call other pure
functions.

You know that. I know that. Why would anyone think it strange?

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron <caron800 googlemail.com>  
wrote:

 On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
  Consider this example:
 <snip>

 Oh well, that's obvious. f() can't call D.invMemberFunc() because
 D.invMemberFunc() isn't pure. Pure functions can only call other pure
 functions.

 You know that. I know that. Why would anyone think it strange?

I think it is because invMemberFunc is invariant. Many read this as
"will not change anything", even though it is not what it means.

-- Simen

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Simen Kjaeraas" wrote
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron  wrote:

 On 09/04/2008, Jason House  wrote:
  Consider this example:
 <snip>

 Oh well, that's obvious. f() can't call D.invMemberFunc() because
 D.invMemberFunc() isn't pure. Pure functions can only call other pure
 functions.

 You know that. I know that. Why would anyone think it strange?

 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

I think there was a suggestion at one point to change const/invariant 
functions to be like:

const(this) int f();

instead of

const int f();

Which I think is much clearer.

-Steve 

Jason House <jason.james.house gmail.com> writes:

Simen Kjaeraas Wrote:

 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron <caron800 googlemail.com>  
 wrote:
 
 On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
  Consider this example:
 <snip>

 Oh well, that's obvious. f() can't call D.invMemberFunc() because
 D.invMemberFunc() isn't pure. Pure functions can only call other pure
 functions.

 You know that. I know that. Why would anyone think it strange?

 
 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.
 
 -- Simen

That's certainly a piece of it, but it's more than that.  A lot of people talk
about pure functions taking invariant data as being enough.  In reality, the
invariant nature is only enough when accessing data without member functions. 
When member functions are involved, the invariant property is not enough.

While those of use paying attention know that it's not enough, it feels quite
strange.  Andrei's slides use multithreading as needing invariance to work. 
When pushed, people say that invariance is necessary but not sufficient and
requires pure instead.  So multithreading requires pure functions and invariant
primitive types.

The current const/invariant stuff has a way of handling member functions that
really doesn't make much sense...  It turns out that most invariant functions
will also require that they're declared pure... so how much sense  does
invariant member functions really make?

I'll toss out the idea that if invariant functions could only access invariant
global state (and invariant static members) that they nearly match the pure
function definition.  In such a situation, nearly all invariant member
functions could be used as part of multi-threaded optimization.

Georg Wrede <georg nospam.org> writes:

Simen Kjaeraas wrote:
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:

 You know that. I know that. Why would anyone think it strange?

 
 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

I seriously think the problem is with the phrase "invMemberFunc is 
invariant".

This leads people to think invariantness is a property of the function, 
instead of it merely requiring an invariant "this".

Maybe we should figure out another way of stating it.

Jason House <jason.james.house gmail.com> writes:

Georg Wrede Wrote:

 Simen Kjaeraas wrote:
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:

 
 You know that. I know that. Why would anyone think it strange?

 
 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

 
 I seriously think the problem is with the phrase "invMemberFunc is 
 invariant".
 
 This leads people to think invariantness is a property of the function, 
 instead of it merely requiring an invariant "this".
 
 Maybe we should figure out another way of stating it.

Is that really the best solution?  Why not have do what people nievely think it
does?  The code optimizer would benefit from that as well.

"Lionello Lunesu" <lionello lunesu.remove.com> writes:

"Jason House" <jason.james.house gmail.com> wrote in message 
news:ftiuj8$mob$1 digitalmars.com...
 Georg Wrede Wrote:

 Simen Kjaeraas wrote:
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:

 You know that. I know that. Why would anyone think it strange?

 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

 I seriously think the problem is with the phrase "invMemberFunc is
 invariant".

 This leads people to think invariantness is a property of the function,
 instead of it merely requiring an invariant "this".

 Maybe we should figure out another way of stating it.

 Is that really the best solution?  Why not have do what people nievely 
 think it does?  The code optimizer would benefit from that as well.

I agree.. And one less keyword, which, it seems, is a goal in itself.

L. 

Georg Wrede <georg nospam.org> writes:

Lionello Lunesu wrote:
 
 "Jason House" <jason.james.house gmail.com> wrote in message 
 news:ftiuj8$mob$1 digitalmars.com...
 
 Georg Wrede Wrote:
 Simen Kjaeraas wrote:
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:

 You know that. I know that. Why would anyone think it strange?

 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

 I seriously think the problem is with the phrase "invMemberFunc is
 invariant".

 This leads people to think invariantness is a property of the function,
 instead of it merely requiring an invariant "this".

 Maybe we should figure out another way of stating it.

 Is that really the best solution?  Why not have do what people nievely 
 think it does?  The code optimizer would benefit from that as well.

 
 I agree.. And one less keyword, which, it seems, is a goal in itself.

I wasn't thinking of changing D, I was thinking more what we should 
*say* when we talk about invariantness and functions.

The phrase "f is invariant" really does not say that it wants something 
"invariant". In English it says that "there is a property invariantness, 
that f is". It's like saying somebody is Chinese. That is not the same 
as saying she wants Chinese food.

Any newcomer to this NG who doesn't have an extensive cultural 
background in C-like languages, will have a hard time before he realises 
that "f is invariant" actually only means "f loves an invariant 'this'".

Jason House <jason.james.house gmail.com> writes:

Georg Wrede Wrote:

 Lionello Lunesu wrote:
 
 "Jason House" <jason.james.house gmail.com> wrote in message 
 news:ftiuj8$mob$1 digitalmars.com...
 
 Georg Wrede Wrote:
 Simen Kjaeraas wrote:
 On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron wrote:

 You know that. I know that. Why would anyone think it strange?

 I think it is because invMemberFunc is invariant. Many read this as
 "will not change anything", even though it is not what it means.

 I seriously think the problem is with the phrase "invMemberFunc is
 invariant".

 This leads people to think invariantness is a property of the function,
 instead of it merely requiring an invariant "this".

 Maybe we should figure out another way of stating it.

 Is that really the best solution?  Why not have do what people nievely 
 think it does?  The code optimizer would benefit from that as well.

 
 I agree.. And one less keyword, which, it seems, is a goal in itself.

 
 I wasn't thinking of changing D, 

Right, but I am ;)


 I was thinking more what we should 
 *say* when we talk about invariantness and functions.

If we have to say special qualifiers every time we talk about stuff, it's a
broken definition :(  The less corner cases there are, the easier it'll be to
discuss, the easier it'll be to learn, and the lower the potential for compiler
bugs will be...

Georg Wrede <georg nospam.org> writes:

Jason House wrote:
 Consider this example:
 
 class D{
   void invMemberFunc() invariant; // not pure
 }
 
 class C{
   int f(invariant D) invariant pure{
     D.invMemberFunc(); // illegal
   }
 }

((Upon proofreading it dawned to me that the example above may contain 
errors, but for the sake of clarity, somebody still explain.))

Not being an expert on this stuff, I have to ask:

   void invMemberFunc() invariant; // not pure

What does it actually mean? A function taking no arguments, returning 
nothing? If it has no side effect, then it has no bearing on the 
program, therefore, it essentially is a null function, doing nothing. 
Or, if it has side effects, then the whole question is about: Do we 
allow or disallow pure functions calling member functions with 
intra-object side-effects. (And as far as I understand it, currently 
this is considered illegal, but just may become legal in D3 -- if it 
/really/ then seems like a warranted idea.) (1)

And then it is /invariant/. What exactly does the word invariant mean in 
a function definition when it's after the function name? That it 
requires the argument to be an invariant? (I sure hope it's not some 
property "invariant" of the function, meaning somehow that it doesn't 
change (whatever)).

Along the same lines (please anybody explain),

   int f(invariant D) invariant { ... } //omitting pure here for now

What does that mean? Like, one would understand the latter invariant on 
the line to mean that you only can pass invariant data to the function, 
but then the former invariant on the line would be superfluous, right?

And then,

    int f(invariant D) invariant pure{ ... }

If the function is pure, then should that now implicitly demand an 
invariant argument? (At least as far as I've understood anything about 
this D version.) And therefore actually /both/ invariants are 
superfluous in the definition.

Finally,

 class D{
   void invMemberFunc() invariant; // not pure
 }
 
 class C{
   int f(invariant D) invariant pure{
     D.invMemberFunc(); // illegal
   }
 }

Since invMemberFunc is not pure, then using it in f should really be 
illegal. Syntactically, that is, per definition. This because other 
alternatives would be too complicated for the compiler (and the 
programmer) to be practical.

The above example might be clearer (at least to me :-), and depending of 
  course on what exactly you are asking... ) if it said

class D {
   int invMemberFunc(int i) invariant; // not pure
}

class C {
   int e;
   invariant int g;
   int f(invariant D d) invariant pure{
     e = d.invMemberFunc(g); // illegal
   }
}

But again, I'm not expert enough to know for sure what you are asking 
here, so this may not be equivalent.

But, if it were like this, then using invMemberFunc should still be illegal.

---

(1) Which leads to the tought: since a pure function can't call other 
functions to use their side effects, the only reason left to call a 
function is to get it's value. From which follows that calling void 
functions should be made illegal! On the grounds that there is no point 
in calling such a function in the first place. (This as part of the 
"barriers" mentioned in the post 69190 "What is pure and what is not pure".)

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
   void invMemberFunc() invariant; // not pure
  What does it actually mean?

The word "invariant", in this position, means that the function's
hidden "this" parameter is typed invariant.


 A function taking no arguments, returning
 nothing? If it has no side effect,

The compiler doesn't know it has no side effects, because it's not
declared pure, so it has to err on the side of caution.


 Do we allow or disallow pure
 functions calling member functions with intra-object side-effects.

We disallow pure functions from calling non-pure functions.


  And then it is /invariant/. What exactly does the word invariant mean in a
 function definition when it's after the function name?

See above. It means that "this" is invariant. From the caller's point
of view, it means that the member function cannot be called from a
non-invariant instance.


  Along the same lines (please anybody explain),

   int f(invariant D) invariant { ... } //omitting pure here for now

  What does that mean?

Nothing. It's not legal D.


    int f(invariant D) invariant pure{ ... }

Also not legal D. Although the following would be

    int f(invariant D d) { ... } invariant pure

And that would mean that f takes as it's parameters the hidden
invariant parameter "this" and an invariant D d. It is pure, and
returns an int.


  If the function is pure, then should that now implicitly demand an
 invariant argument?

That's been suggested before. No reply from the Powers That Be yet.


  Finally,
  Since invMemberFunc is not pure, then using it in f should really be
 illegal.

Yes


  (1) Which leads to the tought: since a pure function can't call other
 functions to use their side effects, the only reason left to call a function
 is to get it's value. From which follows that calling void functions should
 be made illegal!

Well, they can be optimised away, at least.

Georg Wrede <georg nospam.org> writes:

Joining Janice's two replies.

Janice Caron wrote:
 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
 
 void invMemberFunc() invariant; // not pure
 What does it actually mean?

 
 The word "invariant", in this position, means that the function's
 hidden "this" parameter is typed invariant.

Ok.

A function taking no arguments, returning
nothing? If it has no side effect,

 
 The compiler doesn't know it has no side effects, because it's not
 declared pure, so it has to err on the side of caution.

Ok.

 Do we allow or disallow pure
 functions calling member functions with intra-object side-effects.

 
 We disallow pure functions from calling non-pure functions.

Ok.

 And then it is /invariant/. What exactly does the word invariant mean in a
function definition when it's after the function name?

 
 See above. It means that "this" is invariant. From the caller's point
 of view, it means that the member function cannot be called from a
 non-invariant instance.

Ok.

 Along the same lines (please anybody explain),

  int f(invariant D) invariant { ... } //omitting pure here for now

 What does that mean?

 
 My apologies. Of course it's legal. I was misreading. (Although you
 did miss out the variable name for D. Let's call it d)

Right.

 So it means that "this" is invariant, and that d is invariant.

To be precise, it /requires/ that "this" is invariant, right?

   int f(invariant D) invariant pure{ ... }

 Also I screwed up. Yes, that is legal D. My apologies again. It means
 as above, plus the function is also pure.
 
     int f(invariant D d) { ... } invariant pure
 
 And that would mean that f takes as it's parameters the hidden
 invariant parameter "this" and an invariant D d. It is pure, and
 returns an int.

Which is precisely the same as the previous one?


Additionally, I seem to remember that stuff like

kljal alsje fss laskef(kajs aks) {

   // potentially hundreds of lines here

} lksjd afaf

was frowned upon in D. Has this changed? The point being, it's bad to 
have some part of the signature geographically remote from the rest.

 If the function is pure, then should that now implicitly demand an
invariant argument?

 
 That's been suggested before. No reply from the Powers That Be yet.

Maybe it's too obvious to even comment upon? :-) I mean, what if it's 
not implicit? Then folks doing pure functions would have to write 
invariant all over the place, *PLUS*, any newcomer would take it for 
granted that since you have to write it, then there *can* be pure 
functions not taking invariants! So, IMNSHO, there's no other way than 
to make them implicit, and therefore forbidden as redundant.

 Finally, Since invMemberFunc is not pure, then using it in f should
 really be illegal.

 
 Yes

Good.

 (1) Which leads to the thought: since a pure function can't call other
 functions to use their side effects, the only reason left to call a function
 is to get it's value. From which follows that calling void functions should
 be made illegal!

 
 Well, they can be optimised away, at least.

They can be flatly removed! If they don't return a value, and don't 
change anything, what's left?!

Actually, to be more precise:

  - A pure function can only call other pure functions.
  - Any pure function has to return a value.
  - In a pure function, ignoring the return value of a called function 
is an error.

This is even stronger than (1) above, it is clearer,
and it's *right*.

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
    int f(invariant D d) { ... } invariant pure

 And that would mean that f takes as it's parameters the hidden
 invariant parameter "this" and an invariant D d. It is pure, and
 returns an int.

  Which is precisely the same as the previous one?

No, again, that we my fault for misreading the question, and for which
I now feel very silly. The qualifiers are /not/ allowed following the
function body, and I apologise for giving that impression. However,
the following are all equivalent.

    int f(invariant D d) invariant pure { ... }
    int f(invariant D d) pure invariant { ... }
    pure int f(invariant D d) invariant { ... }
    invariant int f(invariant D d) pure { ... }
    pure invariant int f(invariant D d) { ... }
    invariant pure int f(invariant D d) { ... }

...unless of course pure implies invariant, which we would hope, in
which case you only have one of

    int f(D d) pure { ... }
    pure int f(D d) { ... }


  Additionally, I seem to remember that stuff like

  kljal alsje fss laskef(kajs aks) {

   // potentially hundreds of lines here

  } lksjd afaf

  was frowned upon in D. Has this changed?

No. Apologies for confusion.


 Well, they can be optimised away, at least.

  They can be flatly removed!

That's what "optimised away" means. :-)


   - Any pure function has to return a value.

To be /useful/ it has to return a value. To be /syntactically
correct/, probably not. For example:

    void doNothing(int x) pure
    {
    }

    int doSomething(int x) pure
    {
        doNothing(x);
        return x + 1;
    }

That looks OK to me. doNothing() will be optimised away completely,
but I think it needs to be /allowed/ because such a function could
conceivably arise as a result of template instantiation or string
mixin.


   - In a pure function, ignoring the return value of a called function is an
 error.

I see no reason why that should be an error. Again, generic
programming might result in such code.


  This is even stronger than (1) above, it is clearer,
  and it's *right*.

Sure, but you don't need to outlaw code that does nothing. :-)

Jason House <jason.james.house gmail.com> writes:

Janice Caron Wrote:

 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
  This is even stronger than (1) above, it is clearer,
  and it's *right*.

 
 Sure, but you don't need to outlaw code that does nothing. :-)

D already outlaws having code that isn't run.  I would prefer for code that
does nothing to be considered an error.  Of course, with most functions being
impure, that's tough to enforce.  With pure functions, it should be easy.

"Lionello Lunesu" <lionello lunesu.remove.com> writes:

"Jason House" <jason.james.house gmail.com> wrote in message 
news:ftislk$3m0$1 digitalmars.com...
 Janice Caron Wrote:

 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
  This is even stronger than (1) above, it is clearer,
  and it's *right*.

 Sure, but you don't need to outlaw code that does nothing. :-)

 D already outlaws having code that isn't run.  I would prefer for code 
 that does nothing to be considered an error.  Of course, with most 
 functions being impure, that's tough to enforce.  With pure functions, it 
 should be easy.

Why? If pure-ness (uh, purity?) can be checked, it can also be deducted (*), 
so the compiler could optimize/complain in either case.

Tagging a function explicitely as "pure" would only enable a constraint as 
to what other functions can be called, which is something I'd rather see 
solved using more generalized tagging abilities (See Scott Meyers' 
presentation on red-code, green-code [1]).

Maybe identifiers between the parameter list and the function body could 
work as ad-hoc constraints. This would work for pure and nothrow, and the 
user can add whatever identifier/constraint s/he wants.

L.

(*) Is this conclusion correct? It feels correct, but I don't think I can 
proof it.

[1] http://www.nwcpp.org/Downloads/2007/redcode_-_updated.pdf 

Bill Baxter <dnewsgroup billbaxter.com> writes:

Lionello Lunesu wrote:
 
 "Jason House" <jason.james.house gmail.com> wrote in message 
 news:ftislk$3m0$1 digitalmars.com...
 Janice Caron Wrote:

 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
  This is even stronger than (1) above, it is clearer,
  and it's *right*.

 Sure, but you don't need to outlaw code that does nothing. :-)

 D already outlaws having code that isn't run.  I would prefer for code 
 that does nothing to be considered an error.  Of course, with most 
 functions being impure, that's tough to enforce.  With pure functions, 
 it should be easy.

 
 Why? If pure-ness (uh, purity?) can be checked, it can also be deducted 
 (*), so the compiler could optimize/complain in either case.

I was thinking along the same lines last week or so.  A lot of things
about a method signature can be deduced from what's inside.  Including
types of the arguments in many cases.  Languages like ML take this to
the extreme.  But the point of putting the info explicitly in the
signature is so that
A) the compiler doesn't need to see the implementation right away to
tell what's inside (separate compilation).
B) Joe Programmer doesn't have to see the implementation to know if he
can call it or not (documentation).
C) Fred Programmer can declare his intent to Joe that the method work in
such a way, and the compiler can tell Fred if what he though was true is
not (verification).

CTFE-ness is automatically deduced by the compiler, but using CTFE
always requires access to the source of the method so A) is not an
issue.  Still it might be nice to have a "ctfe" tag for purpose B).

So I think deduction of such stuff is not really viable overall.
Perhaps it could be allowed for templates though?  The source is
required to be available for those anyway.

--bb

"Janice Caron" <caron800 googlemail.com> writes:

On 10/04/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:
 Janice Caron Wrote:

 ...

 D already outlaws having code that isn't run.  I would prefer for code
 that does nothing to be considered an error.  Of course, with most functions
 being impure, that's tough to enforce.  With pure functions, it should be

  >easy.

No I did not. That was Jason House. Please be careful with your level
of nesting!

"Lionello Lunesu" <lionello lunesu.remove.com> writes:

"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.374.1207809416.2351.digitalmars-d puremagic.com...
 On 10/04/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:
 Janice Caron Wrote:

 ...

 D already outlaws having code that isn't run.  I would prefer for code
 that does nothing to be considered an error.  Of course, with most 
 functions
 being impure, that's tough to enforce.  With pure functions, it should 
 be

  >easy.

 No I did not. That was Jason House. Please be careful with your level
 of nesting!

Uh, the "..." part contains what you've said, not what follows it, so the 
quote was right (at least it looks just fine in my reader).

L. 

"Janice Caron" <caron800 googlemail.com> writes:

On 10/04/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:
  Why? If pure-ness (uh, purity?) can be checked, it can also be deducted

"purity" is the right word. (But "deducted" should be "deduced" :-))

 (*), so the compiler could optimize/complain in either case.

It would slow down compilation no end though. For example, a pure
function is not allowed to call non-pure functions. Without the "pure"
keyword, you'd have to follow through every function call recursively,
and that could take a long time.

Moreover, just because the compiler decides the function is impure,
that doesn't necessarily mean that the programmer /intended/ for it to
be impure. Perhaps there was a bug? Perhaps there was a silly, simple,
one line bug, that the programmer could fix in a jiffy if the compiler
would only say "Error: Line 53: Pure function cannot do XYZ"? It is
far better for the programmer to document their intentions, so that
the compiler can check that those intentions are actually met.

"Lionello Lunesu" <lionello lunesu.remove.com> writes:

"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.375.1207810102.2351.digitalmars-d puremagic.com...
 On 10/04/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:
  Why? If pure-ness (uh, purity?) can be checked, it can also be deducted

 "purity" is the right word. (But "deducted" should be "deduced" :-))

:-) thanks.

 (*), so the compiler could optimize/complain in either case.

 It would slow down compilation no end though. For example, a pure
 function is not allowed to call non-pure functions. Without the "pure"
 keyword, you'd have to follow through every function call recursively,
 and that could take a long time.

Yeah, but you'll have to visit those functions anyway, because you're 
compiling. Granted, header files should explicitely mention pure/notpure, 
and to make it safe, it must be mangled.

 Moreover, just because the compiler decides the function is impure,
 that doesn't necessarily mean that the programmer /intended/ for it to
 be impure. Perhaps there was a bug? Perhaps there was a silly, simple,
 one line bug, that the programmer could fix in a jiffy if the compiler
 would only say "Error: Line 53: Pure function cannot do XYZ"? It is
 far better for the programmer to document their intentions, so that
 the compiler can check that those intentions are actually met.

Good point.

L. 

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Lionello Lunesu wrote:
 
 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.375.1207810102.2351.digitalmars-d puremagic.com...
 On 10/04/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:
  Why? If pure-ness (uh, purity?) can be checked, it can also be deducted

 "purity" is the right word. (But "deducted" should be "deduced" :-))

 
 :-) thanks.
 
 (*), so the compiler could optimize/complain in either case.

 It would slow down compilation no end though. For example, a pure
 function is not allowed to call non-pure functions. Without the "pure"
 keyword, you'd have to follow through every function call recursively,
 and that could take a long time.

 
 Yeah, but you'll have to visit those functions anyway, because you're 
 compiling. Granted, header files should explicitely mention 
 pure/notpure, and to make it safe, it must be mangled.

Visited? Yes.
Look at their body? Not if they're in a different module, AFAICT.
If the function is in another module then the declaration should be 
enough (the fact that .di "headers" work confirms this), and the body 
can effectively be ignored beyond checking syntactical correctness (i.e. 
checking that it *could* be valid code provided all identifiers it uses 
resolve to stuff of appropriate types, but not actually looking up any 
of the identifiers mentioned in it).

Georg Wrede <georg nospam.org> writes:

Janice Caron wrote:
 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
 
 However,
 the following are all equivalent.
 
     int f(invariant D d) invariant pure { ... }
     int f(invariant D d) pure invariant { ... }
     pure int f(invariant D d) invariant { ... }
     invariant int f(invariant D d) pure { ... }
     pure invariant int f(invariant D d) { ... }
     invariant pure int f(invariant D d) { ... }

Thanks. (Although I'd really love to see less possibilities here. 
Grepping for code, quickly skimming others' code, and for me personally, 
making less mistakes, ...)

 ...unless of course pure implies invariant, which we would hope, in
 which case you only have one of
 
     int f(D d) pure { ... }
     pure int f(D d) { ... }

Excellent.

Well, they can be optimised away, at least.

 They can be flatly removed!

 
 That's what "optimised away" means. :-)

:-)

  - Any pure function has to return a value.

 
 To be /useful/ it has to return a value. To be /syntactically
 correct/, probably not. For example:
 
     void doNothing(int x) pure
     {
     }
 
     int doSomething(int x) pure
     {
         doNothing(x);
         return x + 1;
     }
 
 That looks OK to me. doNothing() will be optimised away completely,
 but I think it needs to be /allowed/ because such a function could
 conceivably arise as a result of template instantiation or string
 mixin.
 
  - In a pure function, ignoring the return value of a called function is an
error.

 
 I see no reason why that should be an error. Again, generic
 programming might result in such code.
 
 This is even stronger than (1) above, it is clearer,
 and it's *right*.

 
 Sure, but you don't need to outlaw code that does nothing. :-)

In the same manner as unreachable code is an error with many compilers, 
this might be polite.

But, I do believe the template issue!

guslay <guslay gmail.com> writes:

Janice Caron Wrote:

 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
 
     int f(invariant D d) invariant pure { ... } 

Shouldn't it be

int f(invariant D d) pure { ... } 

Pure functions are a subset of invariant functions, no?

Bill Baxter <dnewsgroup billbaxter.com> writes:

guslay wrote:
 Janice Caron Wrote:
 
 On 09/04/2008, Georg Wrede <georg nospam.org> wrote:

     int f(invariant D d) invariant pure { ... } 

 
 Shouldn't it be
 
 int f(invariant D d) pure { ... } 
 
 Pure functions are a subset of invariant functions, no?

Just a nitpick, but "pure" applies to the function as a whole.  So 
there's no reason not to put it at the head with 'static' and protection 
levels.  There's no 'pure int'.  It's not going to be a type 
constructor.  Just a storage class.  AFAIK.

--bb

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"guslay" wrote
 Janice Caron Wrote:

 On 09/04/2008, Georg Wrede wrote:

     int f(invariant D d) invariant pure { ... }

 Shouldn't it be

 int f(invariant D d) pure { ... }

 Pure functions are a subset of invariant functions, no?

No.

A function does not necessarily need to take an invariant 'this' pointer to 
be pure.

For example:

class C
{
   invariant int x;
   pure int getX() { return x;}
}

void foo()
{
C c = new C;
c.getX(); // ok
}

-Steve 

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:
  A function does not necessarily need to take an invariant 'this' pointer to
  be pure.

  For example:
  <snip>

Trouble is, that means we'll end up having to write "invariant" all
over the place, and it's really quite a long keyword!

Maybe Walter will let us shorten it to "in"? (Yes, I know "in" means
"const" right now).

guslay <guslay gmail.com> writes:

Steven Schveighoffer Wrote:

 "guslay" wrote
 Janice Caron Wrote:

 On 09/04/2008, Georg Wrede wrote:

     int f(invariant D d) invariant pure { ... }

 Shouldn't it be

 int f(invariant D d) pure { ... }

 Pure functions are a subset of invariant functions, no?

 
 No.
 
 A function does not necessarily need to take an invariant 'this' pointer to 
 be pure.
 
 For example:
 
 class C
 {
    invariant int x;
    pure int getX() { return x;}
 }
 
 void foo()
 {
 C c = new C;
 c.getX(); // ok
 }
 
 -Steve 

c.getX() is equivalent to " int getX( ref C this ) ", so its not pure. 

I will restate: Pure member functions are a subset of invariant member
functions.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"guslay" wrote
 Steven Schveighoffer Wrote:

 "guslay" wrote
 Janice Caron Wrote:

 On 09/04/2008, Georg Wrede wrote:

     int f(invariant D d) invariant pure { ... }

 Shouldn't it be

 int f(invariant D d) pure { ... }

 Pure functions are a subset of invariant functions, no?

 No.

 A function does not necessarily need to take an invariant 'this' pointer 
 to
 be pure.

 For example:

 class C
 {
    invariant int x;
    pure int getX() { return x;}
 }

 void foo()
 {
 C c = new C;
 c.getX(); // ok
 }

 -Steve

 c.getX() is equivalent to " int getX( ref C this ) ", so its not pure.

AFAIK, C.getX() is equivalent to int getX(C this).

i.e. you can't change the this pointer to point to something else during the 
function.

I don't see why it's not pure.  I'm questioning the assertion that pure 
functions MUST take invariant reference types.  They can take mutable ones 
as long as they do not reference mutable data within the type.  It's the 
same reason you will be able to pass strings to a pure function.  A string 
is mutable, but the data it points to is not.

-Steve 

guslay <guslay gmail.com> writes:

Steven Schveighoffer Wrote:

 AFAIK, C.getX() is equivalent to int getX(C this).
 
 i.e. you can't change the this pointer to point to something else during the 
 function.
 
 I don't see why it's not pure.  I'm questioning the assertion that pure 
 functions MUST take invariant reference types.  They can take mutable ones 
 as long as they do not reference mutable data within the type.  It's the 
 same reason you will be able to pass strings to a pure function.  A string 
 is mutable, but the data it points to is not.
 
 -Steve 
 

I can't think of a counter-example, you might be correct.
 

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:
  It's the
  same reason you will be able to pass strings to a pure function.  A string
  is mutable, but the data it points to is not.

No, that's because of Andrei's

    RULE 3:
    T implicitly converts to and from invariant(T) iff T refers to no
mutable memory

(from accu-functional.pdf)
Therefore, string implicitly casts to invariant(string).

Perhaps then, we may say that the parameters of a pure function should
be invariant, or implicitly castable to invariant?

Of course, it's /possible/ to write a pure function that takes mutable
pointers, e.g.

    int f(char[] s) pure?
    {
        return 42;
    }

but do we care? Wouldn't it just be easier to make that illegal and
insist that the programmer rewrite the function more sensibly?

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Janice Caron" wrote
 On 09/04/2008, Steven Schveighoffer wrote:
  It's the
  same reason you will be able to pass strings to a pure function.  A 
 string
  is mutable, but the data it points to is not.

 No, that's because of Andrei's

    RULE 3:
    T implicitly converts to and from invariant(T) iff T refers to no
 mutable memory

Hm.. I glossed over that rule :)  But by the same rule, my example class C 
should be implicitly castable to invariant, but in the case where C has 
invariant and mutable parts, then this is not the case...  I was thinking a 
different rule (for pure functions) would be more appropriate:

Disallow access to non-invariant data

Should be changed to:

Only allow access to invariant and local data.

 (from accu-functional.pdf)
 Therefore, string implicitly casts to invariant(string).

 Perhaps then, we may say that the parameters of a pure function should
 be invariant, or implicitly castable to invariant?

Hopefully not the former, as working with invariant data when one doesn't 
have to makes things really cumbersome.  If it's implicitly castable to 
invariant, then it's implicitly castable from invariant, I'd rather have the 
mutable version :)

 Of course, it's /possible/ to write a pure function that takes mutable
 pointers, e.g.

    int f(char[] s) pure?
    {
        return 42;
    }

 but do we care? Wouldn't it just be easier to make that illegal and
 insist that the programmer rewrite the function more sensibly?

I'm thinking more of the case where an argument is a mutable stack pointer 
(meaning it is a pointer, but only exists in the pure function's stack) to a 
chunk of data that has both mutable and invariant pieces.  i.e.:

class C
{
    int *m;
    invariant(int *) i;
}

pure int getI(C c)
{
    return *i;
}

There may be a reason to use i, but not m in a pure function.  Why should 
pure restrict this?  It's technically correct and statically verifiable.

-Steve 

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:
  class C
  {
     int *m;
     invariant(int *) i;
  }

  pure int getI(C c)
  {
     return *i;
  }

  There may be a reason to use i, but not m in a pure function.  Why should
  pure restrict this?  It's technically correct and statically verifiable.

Except that there's no way to initialise i.

My understanding of the whole raw vs cooked thing in
accu-functional.pdf is that it's a way of making an entirely invariant
class. There would still be no way to create a class with some members
invariant and others not, except for those that can be initialised at
compile time.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Janice Caron" wrote
 On 09/04/2008, Steven Schveighoffer wrote:
  class C
  {
     int *m;
     invariant(int *) i;
  }

  pure int getI(C c)
  {
     return *i;
  }

  There may be a reason to use i, but not m in a pure function.  Why 
 should
  pure restrict this?  It's technically correct and statically verifiable.

 Except that there's no way to initialise i.

 My understanding of the whole raw vs cooked thing in
 accu-functional.pdf is that it's a way of making an entirely invariant
 class. There would still be no way to create a class with some members
 invariant and others not, except for those that can be initialised at
 compile time.

I think this is a limitation that should be lifted, as there may be reasons 
to have an invariant member of a class that is set upon construction.  I 
can't see any reason to disallow it.

-Steve 

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:
  A function does not necessarily need to take an invariant 'this' pointer to
  be pure.

  For example:


  class C
  {
    invariant int x;

    pure int getX() { return x;}
  }

  void foo()
  {
  C c = new C;
  c.getX(); // ok
  }

OK, I'm gonna risk it. :-)

Andrei proposes a new feature, *invariant constructors*, which are
constructors with special rules to ensure that pointers to mutable
memory, however, my interpretation of accu-functional.pdf is that
invariant constructors will cause the /entire class/ to be created
invariant. Thus, one would write

    class C
    {
        int x;

        this(int n) invariant
        {
            x = n;
        }

       int getX() invariant pure
       {
           return x;
       }
    }

    invariant c = new C(4);
    int n = c.getX;

My interpretation is that the invariant constructor will construct a
/completely invariant/ object. In that case, there can never be any
such thing as a non-invariant C.

What you're describing is something different - a non-invariant class
with invariant members. Well, the only time you can assign an
invariant member is at compile-time. That means they have to be
assigned with compile-time constants. That, in turn, means they might
as well be static, because they are not going to differ from instance
to instance. And /that/ means you can rewrite your counterexample as

    class C
    {
        static invariant int x = 4;

        static int getX() pure
        {
            return x;
        }
    }

    auto c = new C(4);
    int n = c.getX;

Now getX() is pure because it's static, and therefore /has/ no this pointer.

In conclusion, it may well be that D will insist that all parameters
of pure functions be completely invariant. I don't know that for
/sure/, but that would be my guess.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Wed, 09 Apr 2008 20:40:38 +0200, Janice Caron <caron800 googlemail.co=
m>  =

wrote:

 What you're describing is something different - a non-invariant class
 with invariant members. Well, the only time you can assign an
 invariant member is at compile-time. That means they have to be
 assigned with compile-time constants. That, in turn, means they might
 as well be static, because they are not going to differ from instance
 to instance. And /that/ means you can rewrite your counterexample as

     class C
     {
         static invariant int x =3D 4;

         static int getX() pure
         {
             return x;
         }
     }

     auto c =3D new C(4);
     int n =3D c.getX;

 Now getX() is pure because it's static, and therefore /has/ no this  =

 pointer.

class foo
{
	invariant int bar;
	=

	this()
	{
		bar =3D 4;
	}
}

This works under DMD 2.012. However, this does not work:

class foo
{
	invariant int bar =3D 2;
	=

	this()
	{
		bar =3D 4;
	}
}

There is nothing wrong with having non-static, invariant member variable=
s,  =

which are assigned in the constructor. Of course, you'd get the exact sa=
me  =

result (except for function which require invariant parameters, i.e. pur=
e  =

functions) with a const int.

-- Simen

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
  class foo
  {
         invariant int bar;

         this()
         {
                 bar = 4;
         }
  }

  This works under DMD 2.012.

That's interesting. I did not know that.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Thu, 10 Apr 2008 01:07:51 +0200, Janice Caron <caron800 googlemail.co=
m>  =

wrote:

 On 09/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
  class foo
  {
         invariant int bar;

         this()
         {
                 bar =3D 4;
         }
  }

  This works under DMD 2.012.

 That's interesting. I did not know that.


I can't quite see what would be the difference between const and
invariant in this example.  It's a member variable that is local
to each instance, and cannot be changed. Why should it not work?

-- Simen

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, guslay <guslay gmail.com> wrote:
 Janice Caron Wrote:

  > On 09/04/2008, Georg Wrede <georg nospam.org> wrote:
  >

     int f(invariant D d) invariant pure { ... }

  Shouldn't it be

  int f(invariant D d) pure { ... }

Hopefully, it will just be

    int f(D d) pure {...}

and pure will imply, not only that "this" is invariant, but that all
function arguments are too. However, at this stage we can only guess
at what the syntax will be.

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Janice Caron <caron800 googlemail.com> wrote:
  >   int f(invariant D) invariant { ... } //omitting pure here for now
  >
  >  What does that mean?

 Nothing. It's not legal D.

My apologies. Of course it's legal. I was misreading. (Although you
did miss out the variable name for D. Let's call it d)

So it means that "this" is invariant, and that d is invariant.


  Also not legal D. Although the following would be

Also I screwed up. Yes, that is legal D. My apologies again. It means
as above, plus the function is also pure.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Georg Wrede" wrote
 Jason House wrote:
 Consider this example:

 class D{
   void invMemberFunc() invariant; // not pure
 }

 class C{
   int f(invariant D) invariant pure{
     D.invMemberFunc(); // illegal
   }
 }

 ((Upon proofreading it dawned to me that the example above may contain 
 errors, but for the sake of clarity, somebody still explain.))

 Not being an expert on this stuff, I have to ask:

   void invMemberFunc() invariant; // not pure

 What does it actually mean? A function taking no arguments, returning 
 nothing? If it has no side effect, then it has no bearing on the program, 
 therefore, it essentially is a null function, doing nothing. Or, if it has 
 side effects, then the whole question is about: Do we allow or disallow 
 pure functions calling member functions with intra-object side-effects. 
 (And as far as I understand it, currently this is considered illegal, but 
 just may become legal in D3 -- if it /really/ then seems like a warranted 
 idea.) (1)

 And then it is /invariant/. What exactly does the word invariant mean in a 
 function definition when it's after the function name? That it requires 
 the argument to be an invariant? (I sure hope it's not some property 
 "invariant" of the function, meaning somehow that it doesn't change 
 (whatever)).

It means that the 'this' pointer is invariant.  We don't see the body of the 
function, so we don't know if it's pure or not.

However, the point is, since it is not *declared* pure (we don't know the 
correct syntax for this by the way because it doesn't exist yet!), the 
compiler doesn't know whether it has side effects or not.  Remember, Walter 
and Andrei are trying to create a statically verifyable functional 
programming construct.  This means that the compiler doesn't just *assume* 
that a pure function has no side effects, it *guarantees* that the function 
has no side effects.

 Along the same lines (please anybody explain),

   int f(invariant D) invariant { ... } //omitting pure here for now

 What does that mean? Like, one would understand the latter invariant on 
 the line to mean that you only can pass invariant data to the function, 
 but then the former invariant on the line would be superfluous, right?

Not exactly, it is another way of saying that the 'this' pointer is 
invariant.

 And then,

    int f(invariant D) invariant pure{ ... }

 If the function is pure, then should that now implicitly demand an 
 invariant argument? (At least as far as I've understood anything about 
 this D version.) And therefore actually /both/ invariants are superfluous 
 in the definition.

Not necessarily :)  A pure function can take non-invariant arguments, it 
just can't use the non-invariant pieces of that.  Yeah, I know you just did 
a double take :)  But think about this:

f(int x)

Does x need to be invariant for f to be pure?  No, because every time we 
call x, we create a COPY of x on the stack, which means f has it's own 
private copy that isn't invariant, but f is guaranteed that nothing else 
will change it.  Now if we have:

f(int *x)

Does x need to be invariant for f to be pure?  Actually, no :)  Because f is 
STILL given a stack variable, which happens to be a pointer to mutable data. 
If f dereferences x, then it cannot be pure unless x is invariant.  See the 
difference?  Now the real crux of the issue:

class C
{
   invariant int x;
   int y;
}

f(C c)

Does c need to be invariant for f to be pure?  No.  Because c is still a 
stack variable, which is a reference to an instance of C.  However, in order 
for f to be declared pure, it can only access c.x, it cannot access c.y, 
because c.y might change.

What about structs?

struct S
{
   int x;
}

f(S s)

Again, s does not need to be invariant, because the entire struct is copied 
onto the stack.  This is similar to the f(int) case.

f(S *s)

Now, f can still be pure, but it is not allowed to dereference s.

The rules for pure are:

can only access:
- local variables (mutable, invariant or const)
- invariant data that is referenced by local variables (a class is 
intrinsically a reference, so class instances fall under this category)
- pure functions

There are interesting puzzles that I'm not sure how they will be solved. 
For example:

pure int f()
{
   char[] c = new char[15];
   c[0] = 'h'; // does this compile?
}

Does c need to be invariant to access members of the array?  Clearly from 
this code, you can see that c is private to f.  But under the rules, the 
data c references is not invariant, and so should be inaccessible.  How will 
the compiler make this distinction?

 Finally,

 class D{
   void invMemberFunc() invariant; // not pure
 }

 class C{
   int f(invariant D) invariant pure{
     D.invMemberFunc(); // illegal
   }
 }

 Since invMemberFunc is not pure, then using it in f should really be 
 illegal. Syntactically, that is, per definition. This because other 
 alternatives would be too complicated for the compiler (and the 
 programmer) to be practical.

 The above example might be clearer (at least to me :-), and depending of 
 course on what exactly you are asking... ) if it said

 class D {
   int invMemberFunc(int i) invariant; // not pure
 }

 class C {
   int e;
   invariant int g;
   int f(invariant D d) invariant pure{
     e = d.invMemberFunc(g); // illegal
   }
 }

Whether invMemberFunc takes or returns an int or not is irrelevant :)  The 
fact that it is invariant means it can still might change global data, and 
so it might not be pure.  It could be pure in the sense that it does not 
change global data, but because we didn't declare it pure, the compiler 
cannot know whether it is pure or not, and so it errs on the side of 
caution.

Note that passing in an int and returning an int does not mean it can't be 
pure.  I know you didn't get that when you wrote the post, but I want to 
emphasize it for other readers...

 (1) Which leads to the tought: since a pure function can't call other 
 functions to use their side effects, the only reason left to call a 
 function is to get it's value. From which follows that calling void 
 functions should be made illegal! On the grounds that there is no point in 
 calling such a function in the first place. (This as part of the 
 "barriers" mentioned in the post 69190 "What is pure and what is not 
 pure".)

This is true, calling a pure function which returns nothing makes no sense, 
but clearly this function can be pure:

void f() {return;}

as it has no side effects :) Should it be illegal?  I'd say no.  Useless, 
but not illegal.

-Steve 

Georg Wrede <georg nospam.org> writes:

Steven Schveighoffer wrote:
 
 There are interesting puzzles that I'm not sure how they will be solved. 
 For example:
 
 pure int f()
 {
    char[] c = new char[15];
    c[0] = 'h'; // does this compile?
 }
 
 Does c need to be invariant to access members of the array?  Clearly from 
 this code, you can see that c is private to f.  But under the rules, the 
 data c references is not invariant, and so should be inaccessible.  How will 
 the compiler make this distinction?

Before commenting on the rest,

to me it is obvious that c is solely owned by f (because no references 
to c can exist outside of f), and therefore c is considered internal to 
f, so it's legal.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Georg Wrede" wrote
 Steven Schveighoffer wrote:
 There are interesting puzzles that I'm not sure how they will be solved. 
 For example:

 pure int f()
 {
    char[] c = new char[15];
    c[0] = 'h'; // does this compile?
 }

 Does c need to be invariant to access members of the array?  Clearly from 
 this code, you can see that c is private to f.  But under the rules, the 
 data c references is not invariant, and so should be inaccessible.  How 
 will the compiler make this distinction?

 Before commenting on the rest,

 to me it is obvious that c is solely owned by f (because no references to 
 c can exist outside of f), and therefore c is considered internal to f, so 
 it's legal.

The whole problem comes from the parsing.  I'm not a guru when it comes to 
how D's grammar is structured, but I think it's supposed to be 'context 
free'?

So in the single statement:

c[0] = 'h';

and c's type is char[], how can the compiler be sure it's pointing to local 
data without context/analysis?

In my mind, I think that it should be allowed, but I'm just not sure how 
that can be implemented in a guaranteed fashion, and still keep the grammar 
context-free.  If c has it's own special 'pure' type, that's one thing, but 
I'm not sure how that works.  Maybe it just tags c as being local 
internally, just to check for purity...

-Steve 

Georg Wrede <georg nospam.org> writes:

Steven Schveighoffer wrote:
 "Georg Wrede" wrote
Steven Schveighoffer wrote:

There are interesting puzzles that I'm not sure how they will be solved. 
For example:

pure int f()
{
   char[] c = new char[15];
   c[0] = 'h'; // does this compile?
}

Does c need to be invariant to access members of the array?  Clearly from 
this code, you can see that c is private to f.  But under the rules, the 
data c references is not invariant, and so should be inaccessible.  How 
will the compiler make this distinction?

Before commenting on the rest,

to me it is obvious that c is solely owned by f (because no references to 
c can exist outside of f), and therefore c is considered internal to f, so 
it's legal.

 
 The whole problem comes from the parsing.  I'm not a guru when it comes to 
 how D's grammar is structured, but I think it's supposed to be 'context 
 free'?
 
 So in the single statement:
 
 c[0] = 'h';
 
 and c's type is char[], how can the compiler be sure it's pointing to local 
 data without context/analysis?

Well, the localness of c is established with char[] c on the preceding 
line. And since D relies on bounds checking (not in release code, but in 
its Philosophy), c[0] is "local" too, for the purposes of this discussion.

 In my mind, I think that it should be allowed, but I'm just not sure how 
 that can be implemented in a guaranteed fashion, and still keep the grammar 
 context-free.  If c has it's own special 'pure' type, that's one thing, but 
 I'm not sure how that works.  Maybe it just tags c as being local 
 internally, just to check for purity...

The compiler has to keep track of local variables anyhow.

Georg Wrede <georg nospam.org> writes:

Steven Schveighoffer wrote:
 "Georg Wrede" wrote
 
Jason House wrote:

Consider this example:

class D{
  void invMemberFunc() invariant; // not pure
}

class C{
  int f(invariant D) invariant pure{
    D.invMemberFunc(); // illegal
  }
}

((Upon proofreading it dawned to me that the example above may contain 
errors, but for the sake of clarity, somebody still explain.))

Not being an expert on this stuff, I have to ask:

  void invMemberFunc() invariant; // not pure

What does it actually mean? A function taking no arguments, returning 
nothing? If it has no side effect, then it has no bearing on the program, 
therefore, it essentially is a null function, doing nothing. Or, if it has 
side effects, then the whole question is about: Do we allow or disallow 
pure functions calling member functions with intra-object side-effects. 
(And as far as I understand it, currently this is considered illegal, but 
just may become legal in D3 -- if it /really/ then seems like a warranted 
idea.) (1)

And then it is /invariant/. What exactly does the word invariant mean in a 
function definition when it's after the function name? That it requires 
the argument to be an invariant? (I sure hope it's not some property 
"invariant" of the function, meaning somehow that it doesn't change 
(whatever)).

 
 It means that the 'this' pointer is invariant.  We don't see the body of the 
 function, so we don't know if it's pure or not.

Ok. But I strongly resent being able to put the invariant either before 
or after the function name. It really gives the impression that it means 
something else.

 However, the point is, since it is not *declared* pure (we don't know the 
 correct syntax for this by the way because it doesn't exist yet!), the 
 compiler doesn't know whether it has side effects or not.  Remember, Walter 
 and Andrei are trying to create a statically verifyable functional 
 programming construct.  This means that the compiler doesn't just *assume* 
 that a pure function has no side effects, it *guarantees* that the function 
 has no side effects.

 And then,

   int f(invariant D) invariant pure{ ... }

 A pure function can take non-invariant arguments, it 
 just can't use the non-invariant pieces of that.  Yeah, I know you just did 
 a double take :)  But think about this:

In A/W pure, where the reason for all this invariantness is 
optimization, it would seem hard to enforce, so it would be easier to 
simply forbid non-invariant arguments.

 f(int x)
 
 Does x need to be invariant for f to be pure? 

Well, excluding A/W, the pureness of a function is within itself, and 
not in whether the arguments can change. But here it's different.

 No, because every time we 
 call x, we create a COPY of x on the stack, which means f has it's own 
 private copy that isn't invariant, but f is guaranteed that nothing else 
 will change it.  Now if we have:

Generalising this, the point is to be able to make a local copy from 
data that potentially can change? Thus, the compiler can optimize 
relying on the now acquired invariantness.

 f(int *x)
 
 Does x need to be invariant for f to be pure?  Actually, no :)  Because f is 
 STILL given a stack variable, which happens to be a pointer to mutable data. 
 If f dereferences x, then it cannot be pure unless x is invariant.  See the 
 difference?  Now the real crux of the issue:
 
 class C
 {
    invariant int x;
    int y;
 }
 
 f(C c)
 
 Does c need to be invariant for f to be pure?  No.  Because c is still a 
 stack variable, which is a reference to an instance of C.  However, in order 
 for f to be declared pure, it can only access c.x, it cannot access c.y, 
 because c.y might change.

Which would mean that if f initially makes a local copy of c.y, then 
everyting would be ok?

 What about structs?
 
 struct S
 {
    int x;
 }
 
 f(S s)
 
 Again, s does not need to be invariant, because the entire struct is copied 
 onto the stack.  This is similar to the f(int) case.

Ok. And the point being here is that a private copy is made. (Just 
making sure that _stack_ is not the keyword here. It might as well be on 
the heap (for example), /as long as/ f has the only reference to it. Of 
course normally it would be stack, of course.)

 f(S *s)
 
 Now, f can still be pure, but it is not allowed to dereference s.

Which is useless, right? :-) But still "correct".

Finally,

class D{
  void invMemberFunc() invariant; // not pure
}

class C{
  int f(invariant D) invariant pure{
    D.invMemberFunc(); // illegal
  }
}

Since invMemberFunc is not pure, then using it in f should really be 
illegal. Syntactically, that is, per definition. This because other 
alternatives would be too complicated for the compiler (and the 
programmer) to be practical.

The above example might be clearer (at least to me :-), and depending of 
course on what exactly you are asking... ) if it said

class D {
  int invMemberFunc(int i) invariant; // not pure
}

class C {
  int e;
  invariant int g;
  int f(invariant D d) invariant pure{
    e = d.invMemberFunc(g); // illegal
  }
}

 
 Whether invMemberFunc takes or returns an int or not is irrelevant :)  The 
 fact that it is invariant means it can still might change global data, and 
 so it might not be pure.  It could be pure in the sense that it does not 
 change global data, but because we didn't declare it pure, the compiler 
 cannot know whether it is pure or not, and so it errs on the side of 
 caution.

Agreed.

(1) Which leads to the thought: since a pure function can't call other 
functions to use their side effects, the only reason left to call a 
function is to get it's value. From which follows that calling void 
functions should be made illegal! On the grounds that there is no point in 
calling such a function in the first place. (This as part of the 
"barriers" mentioned in the post 69190 "What is pure and what is not 
pure".)

 
 This is true, calling a pure function which returns nothing makes no sense, 
 but clearly this function can be pure:
 
 void f() {return;}
 
 as it has no side effects :) Should it be illegal?  I'd say no.  Useless, 
 but not illegal.

If there wasn't for the risk that this needs to be allowed as a 
potential product of some template stuff, I'd say this should have been 
made illegal, in the same sense as unreachable code: it makes no sense.

Jason House <jason.james.house gmail.com> writes:

Jason House Wrote:

 Janice Caron Wrote:
 
 On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
 The strange thing is that pure functions can't call invariant member functions
of their invariant data.

 
 I don't think that's correct.
 
 [example showing misinterpretation of what I'm talking about]

 
 Consider this example:

[Corrected example - Thanks george]

class D{
  int invMemberFunc() invariant; // not pure
}
 
class C{
  int f(invariant D) invariant pure{
    return D.invMemberFunc(); // illegal
  }
}

Denton Cockburn <diboss hotmail.com> writes:

On Wed, 09 Apr 2008 13:50:59 +0100, Janice Caron wrote:

 On 09/04/2008, Jason House <jason.james.house gmail.com> wrote:
 The strange thing is that pure functions can't call invariant member functions
of their invariant data.

 
 I don't think that's correct.
 
     class C
     {
         int x;
 
         int f() invariant pure
         {
             return x;
         }
     }
 
     invariant c = cast(invariant) new C;
     int n = c.f();
 
 Should work just fine. Of course, the explicit cast necessary to
 create an invariant C in the first place is a bit ugly. Maybe we need
 "inew" to make new invariant objects?
 

Couldn't the compiler insert the cast based on the declaration?

/* compiler inserts the cast since the declaration is
invariant */
invariant c = new C;

This would also make sense for const.  Is this possible? I think it would
be a nice nugget of syntactic sugar.

"Janice Caron" <caron800 googlemail.com> writes:

On 09/04/2008, Denton Cockburn <diboss hotmail.com> wrote:
  > Of course, the explicit cast necessary to
  > create an invariant C in the first place is a bit ugly. Maybe we need
  > "inew" to make new invariant objects?

 Couldn't the compiler insert the cast based on the declaration?

No, because objects created by new are not necessarily transitively
unique. For example

    class C
    {
        int * p;

        this()
        {
            p = &someGlobalVariable;
        }
    }

    invariant C c = cast(invariant) new C;
    someGlobalVariable = 1;

Whoops! c just changed!

The explicit cast makes it the programmer's fault, not the compiler's!

Come to think of it, "inew" would suffer the exact same problem, so it
doesn't solve anything. Looks like there's no easy way to make an
invariant class instance.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Janice Caron" wrote
 On 09/04/2008, Denton Cockburn wrote:
  > Of course, the explicit cast necessary to
  > create an invariant C in the first place is a bit ugly. Maybe we need
  > "inew" to make new invariant objects?

 Couldn't the compiler insert the cast based on the declaration?

 No, because objects created by new are not necessarily transitively
 unique. For example

    class C
    {
        int * p;

        this()
        {
            p = &someGlobalVariable;
        }
    }

    invariant C c = cast(invariant) new C;
    someGlobalVariable = 1;

 Whoops! c just changed!

 The explicit cast makes it the programmer's fault, not the compiler's!

 Come to think of it, "inew" would suffer the exact same problem, so it
 doesn't solve anything. Looks like there's no easy way to make an
 invariant class instance.

Sure there is :)

class C
{
   int *p;
   int q;

   invariant this() // means, 'this' is going to be invariant
   {
       //p = &someGlobalVariable; // fails, p must point to invariant
       q = 5; // allowed by compiler because it's the first time you set q.
       p = &q; // allowed because q is invariant.
   }
}

I think this was outlined in Andrei's presentation about grafting functional 
languages onto imperitive languages.

Of course, it doesn't work today, but I think it would work.

In fact, I think if you have a class like:

class X{}
class C
{
    invariant X x;
}

There is no way to set x anywhere...  I think this needs to be addressed.

-Steve 

Georg Wrede <georg nospam.org> writes:

Janice Caron wrote:
 On 09/04/2008, Denton Cockburn <diboss hotmail.com> wrote:
 
 Of course, the explicit cast necessary to
 create an invariant C in the first place is a bit ugly. Maybe we need
 "inew" to make new invariant objects?

Couldn't the compiler insert the cast based on the declaration?

 
 
 No, because objects created by new are not necessarily transitively
 unique. For example
 
     class C
     {
         int * p;
 
         this()
         {
             p = &someGlobalVariable;
         }
     }
 
     invariant C c = cast(invariant) new C;
     someGlobalVariable = 1;
 
 Whoops! c just changed!
 
 The explicit cast makes it the programmer's fault, not the compiler's!
 
 Come to think of it, "inew" would suffer the exact same problem, so it
 doesn't solve anything. Looks like there's no easy way to make an
 invariant class instance.

It should be illegal to cast objects invariant unless the compiler can 
guarantee the invariantness. So the cast here should produce an error.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Georg Wrede" wrote
 Janice Caron wrote:
 On 09/04/2008, Denton Cockburn wrote:

 Of course, the explicit cast necessary to
 create an invariant C in the first place is a bit ugly. Maybe we need
 "inew" to make new invariant objects?

Couldn't the compiler insert the cast based on the declaration?


 No, because objects created by new are not necessarily transitively
 unique. For example

     class C
     {
         int * p;

         this()
         {
             p = &someGlobalVariable;
         }
     }

     invariant C c = cast(invariant) new C;
     someGlobalVariable = 1;

 Whoops! c just changed!

 The explicit cast makes it the programmer's fault, not the compiler's!

 Come to think of it, "inew" would suffer the exact same problem, so it
 doesn't solve anything. Looks like there's no easy way to make an
 invariant class instance.

 It should be illegal to cast objects invariant unless the compiler can 
 guarantee the invariantness. So the cast here should produce an error.

This cannot be guaranteed by the compiler.  It is depending on you to ensure 
that the object stays invariant. From 
http://www.digitalmars.com/d/2.0/const3.html

"The second way (to create invariant data) is to cast data to invariant. 
When doing so, it is up to the programmer to ensure that no other mutable 
references to the same data exist."

-Steve 

Georg Wrede <georg nospam.org> writes:

Steven Schveighoffer wrote:
 "Georg Wrede" wrote
 
Janice Caron wrote:

On 09/04/2008, Denton Cockburn wrote:


Of course, the explicit cast necessary to
create an invariant C in the first place is a bit ugly. Maybe we need
"inew" to make new invariant objects?

Couldn't the compiler insert the cast based on the declaration?


No, because objects created by new are not necessarily transitively
unique. For example

    class C
    {
        int * p;

        this()
        {
            p = &someGlobalVariable;
        }
    }

    invariant C c = cast(invariant) new C;
    someGlobalVariable = 1;

Whoops! c just changed!

The explicit cast makes it the programmer's fault, not the compiler's!

Come to think of it, "inew" would suffer the exact same problem, so it
doesn't solve anything. Looks like there's no easy way to make an
invariant class instance.

It should be illegal to cast objects invariant unless the compiler can 
guarantee the invariantness. So the cast here should produce an error.

 
 This cannot be guaranteed by the compiler.  It is depending on you to ensure 
 that the object stays invariant. From 
 http://www.digitalmars.com/d/2.0/const3.html
 
 "The second way (to create invariant data) is to cast data to invariant. 
 When doing so, it is up to the programmer to ensure that no other mutable 
 references to the same data exist."

My mistake.

Robert Fraser <fraserofthenight gmail.com> writes:

Lionello Lunesu wrote:
 One thing that I like is that suddenly C++ "const &" construction can be 
 standardized and made safe at the same time! Because of invariant, "in" 
 can safely pass the arguments by ref, instead of by value.

And the compiler can make the decision for you as to which would be more 
efficient on your architecture. Happiness all around.