www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - An old topic (pun intended)

reply Davidson Corry <davidsoncorry comcast.net> writes:
Did D2 ever implement the Eiffel "old" construct? I do not see it 
mentioned in "The D Programming Language", and the only reference I can 
find in the newsgroup is a short discussion in June of 2007 that seemed 
to go nowhere.

If not, has anyone developed a reasonable workaround? Thanks.

-- Davidson

  ============

Brief description: in Eiffel,
       old expr
can be used in post-conditions, and evaluates to the value of
       expr
as of entry to the function. It's useful to help verify that the 
function has done what it was supposed to, but especially powerful when 
used in classes because it complements invariant:  invariant tests what 
has *not* varied (duh),    old expr   helps test what *has* varied to 
ensure that it has varied *correctly*.

For example, the .Add() method of a Container class might in its 
postcondition assert
        assert( count == old count + 1 )
to ensure that *exactly* one element got added, no more and no less
Oct 12 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Davidson Corry:


 Did D2 ever implement the Eiffel "old" construct?


At the moment there no prestate in D. I agree that prestate is an important
sub-feature of contract programming. It was discussed two or three times, but
the discussions didn't produce actual results. I think it was not implemented
because I think Walter thinks D contract programming is a half failure (I don't
agree on this) and because implementing the prestate is a bit tricky. I suggest
to ask about this in the main D newsgroup, and show two use cases too. I think
if enough people show use cases, and someone writes a good enough pull request
for DMD, it will be added to D/DMD.



 If not, has anyone developed a reasonable workaround? Thanks.


In classes inside a debug I have defined handmade "ghost attributes":

debug {
  int ghost1, ghost2;
}

I use them to manually store the prestate that later I want to verify. This is
not a very good solution...

Bye,
bearophile
Oct 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, October 13, 2011 05:35:52 bearophile wrote:

 Davidson Corry:

 Did D2 ever implement the Eiffel "old" construct?


 
 At the moment there no prestate in D. I agree that prestate is an important
 sub-feature of contract programming. It was discussed two or three times,
 but the discussions didn't produce actual results. I think it was not
 implemented because I think Walter thinks D contract programming is a half
 failure (I don't agree on this) and because implementing the prestate is a
 bit tricky.


I don't recall him ever saying anything about contract programming in D being 
a failure in any way. IIRC, old was rejected because it added extra 
complication for little value.

- Jonathan M Davis
Oct 13 2011
next sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote:


 On Thursday, October 13, 2011 05:35:52 bearophile wrote:

 Davidson Corry:

 Did D2 ever implement the Eiffel "old" construct?


 
 At the moment there no prestate in D. I agree that prestate is an
 important sub-feature of contract programming. It was discussed two or
 three times, but the discussions didn't produce actual results. I think
 it was not implemented because I think Walter thinks D contract
 programming is a half failure (I don't agree on this) and because
 implementing the prestate is a bit tricky.


 
 I don't recall him ever saying anything about contract programming in D
 being a failure in any way.


He had mentioned that at some point the implementation of contract 
programming had serious bugs but nobody had complained.


 IIRC, old was rejected because it added
 extra complication for little value.


Yes, there were technical difficulties in making the stack frame at the 
call point available to the stack frame at the exit point.


 
 - Jonathan M Davis


Ali
Oct 13 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/13/2011 07:14 PM, Ali Çehreli wrote:

 On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote:


 On Thursday, October 13, 2011 05:35:52 bearophile wrote:

 Davidson Corry:

 Did D2 ever implement the Eiffel "old" construct?


 At the moment there no prestate in D. I agree that prestate is an
 important sub-feature of contract programming. It was discussed two or
 three times, but the discussions didn't produce actual results. I think
 it was not implemented because I think Walter thinks D contract
 programming is a half failure (I don't agree on this) and because
 implementing the prestate is a bit tricky.


 I don't recall him ever saying anything about contract programming in D
 being a failure in any way.


 He had mentioned that at some point the implementation of contract
 programming had serious bugs but nobody had complained.


 IIRC, old was rejected because it added
 extra complication for little value.


 Yes, there were technical difficulties in making the stack frame at the
 call point available to the stack frame at the exit point.


Why would that be required?
Oct 16 2011
parent Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Sun, 16 Oct 2011 19:09:46 +0200, Timon Gehr wrote:


 On 10/13/2011 07:14 PM, Ali Çehreli wrote:

 On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote:

 IIRC, old was rejected because it added extra complication for little
 value.


 Yes, there were technical difficulties in making the stack frame at the
 call point available to the stack frame at the exit point.


 Why would that be required?


I am not sure myself. I find this thread where Andrei says "Walter tried 
to implement that but it turned out to be very difficult implementation-
wise":

  http://www.digitalmars.com/d/archives/digitalmars/D/
Communicating_between_in_and_out_contracts_98252.html

Ali
Oct 17 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I don't recall him ever saying anything about contract programming in D being 
 a failure in any way.


He said unittesting has changed the why you write code and has significantly
decreased bugs count, while he was not equally happy about contract
programming. From several things he has said, he looks disappointed by D
contract programming.



 IIRC, old was rejected because it added extra 
 complication for little value.


It add some complexity, but I can't agree that it adds little value, this is a
mistake. The prestate increases significantly the usefulness of contract
programming. And I don't remember it being rejected, I just remember the
discussion stopped, like a river dying and drying up in a desert. Do you have a
link of a post where it was rejected? I think there is an enhancement request
about prestate in Bugzilla, and it is open still. Before actually rejecting
this feature, it will need one more good discussion in the main D newsgroup.

----------------------

Ali Çehreli:


 He had mentioned that at some point the implementation of contract
 programming had serious bugs but nobody had complained.


I am not sure, but I think I did complain about some of those bugs. I have some
old bug reports in Bugzilla about contract programming that are open still.

Bye,
bearophile
Oct 13 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 13, 2011 10:57 bearophile wrote:

 Jonathan M Davis:

 IIRC, old was rejected because it added extra
 complication for little value.


 
 It add some complexity, but I can't agree that it adds little value, this
 is a mistake. The prestate increases significantly the usefulness of
 contract programming. And I don't remember it being rejected, I just
 remember the discussion stopped, like a river dying and drying up in a
 desert. Do you have a link of a post where it was rejected? I think there
 is an enhancement request about prestate in Bugzilla, and it is open
 still. Before actually rejecting this feature, it will need one more good
 discussion in the main D newsgroup.


I'd have to go digging, but from what I recall, it was pretty clear that it 
wasn't happening. But since it's not a feature that I care about at all, it's 
not something that I've tracked particularly closely.

- Jonathan M Davis
Oct 13 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I'd have to go digging, but from what I recall, it was pretty clear that it 
 wasn't happening.


I see. And sorry for the tone of my last answer. Don't worry if you don't have
the time to find it.

Bye,
bearophile
Oct 13 2011
prev sibling parent reply Davidson Corry <davidsoncorry comcast.net> writes:
On 10/13/2011 10:57 AM, bearophile wrote:

 Jonathan M Davis:


 I don't recall him ever saying anything about contract programming in D being
a failure in any way.


 He said unittesting has changed the way you write code and has significantly
decreased bugs count, while he was not equally happy about contract
programming. From several things he has said, he looks disappointed by D
contract programming.


 IIRC, old was rejected because it added extra complication for little value.


 It add some complexity, but I can't agree that it adds little value... And I
don't remember it being rejected, I just remember the discussion stopped, like
a river dying and drying up in a desert.


Implementing DbC is tricky, and 'old' particularly so. For instance, 
what if the condition whose state-at-entry you want to inspect at exit 
happens to reside in a base class implemented in a different module? 
(Note that D supports separate compilation while Eiffel doesn't.)

'unittest' is a major win in D, and may as a practical matter alleviate 
much of the need for other kinds of testing. But...
[opinion]
...unit testing and DbC are *orthogonal* or at least complementary, in 
my view. Conceptually, unit testing tests a class or object from the 
*outside* of its public boundaries, while DbC tests the object from 
*within*. They catch different classes (sic) of implementation error. 
Some bugs may be caught both ways, which is great. But some might slip 
by one, only to be caught by the other.

Like any technique (including unit testing) DbC takes practice to learn 
how to do well, and it is new to most programmers even 25 years after 
Meyer brought it to the masses. There's a bootstrapping problem here: if 
DbC isn't fully implemented, it's not as useful. If it's not useful, 
programmers won't use it. If they don't use it, compiler implementers 
won't improve the implementation. And so on.

Look, Walters are in scarce supply, and I don't want to jog their elbows 
on priorities -- they come up with so much other cool stuff! I'm just 
saying, 'old' would be nice.
[/opinion]

-- Davidson
Oct 13 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/13/2011 08:25 PM, Davidson Corry wrote:

 On 10/13/2011 10:57 AM, bearophile wrote:

 Jonathan M Davis:


 I don't recall him ever saying anything about contract programming in
 D being a failure in any way.


 He said unittesting has changed the way you write code and has
 significantly decreased bugs count, while he was not equally happy
 about contract programming. From several things he has said, he looks
 disappointed by D contract programming.


 IIRC, old was rejected because it added extra complication for little
 value.


 It add some complexity, but I can't agree that it adds little value...
 And I don't remember it being rejected, I just remember the discussion
 stopped, like a river dying and drying up in a desert.


 Implementing DbC is tricky, and 'old' particularly so. For instance,
 what if the condition whose state-at-entry you want to inspect at exit
 happens to reside in a base class implemented in a different module?
 (Note that D supports separate compilation while Eiffel doesn't.)

 'unittest' is a major win in D, and may as a practical matter alleviate
 much of the need for other kinds of testing. But...
 [opinion]
 ...unit testing and DbC are *orthogonal* or at least complementary, in
 my view. Conceptually, unit testing tests a class or object from the
 *outside* of its public boundaries, while DbC tests the object from
 *within*. They catch different classes (sic) of implementation error.
 Some bugs may be caught both ways, which is great. But some might slip
 by one, only to be caught by the other.

 Like any technique (including unit testing) DbC takes practice to learn
 how to do well, and it is new to most programmers even 25 years after
 Meyer brought it to the masses. There's a bootstrapping problem here: if
 DbC isn't fully implemented, it's not as useful. If it's not useful,
 programmers won't use it. If they don't use it, compiler implementers
 won't improve the implementation. And so on.

 Look, Walters are in scarce supply, and I don't want to jog their elbows
 on priorities -- they come up with so much other cool stuff! I'm just
 saying, 'old' would be nice.
 [/opinion]

 -- Davidson


I don't agree that 'old' is very difficult to implement. Just evaluate 
what is inside the 'old' before you enter the in contract, store 
somewhere, maybe in hidden local variables, and make the data available 
in the out contract. Eiffel's 'old' does not do more than that.

(but perhaps there are implementation details in DMD that make this more 
difficult than necessary. I don't know.)
Oct 16 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote: 

 I don't agree that 'old' is very difficult to implement. Just evaluate
 what is inside the 'old' before you enter the in contract, store
 somewhere, maybe in hidden local variables, and make the data available
 in the out contract. Eiffel's 'old' does not do more than that.
 
 (but perhaps there are implementation details in DMD that make this more
 difficult than necessary. I don't know.)


What if you're dealing with a class? You'd need to deep copy the entire object 
for it to work. There's no way built into the language to do that (not to 
mention that it would be horrifically inefficient).

- Jonathan M Davis
Oct 16 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/16/2011 07:31 PM, Jonathan M Davis wrote:

 On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote:

 I don't agree that 'old' is very difficult to implement. Just evaluate
 what is inside the 'old' before you enter the in contract, store
 somewhere, maybe in hidden local variables, and make the data available
 in the out contract. Eiffel's 'old' does not do more than that.

 (but perhaps there are implementation details in DMD that make this more
 difficult than necessary. I don't know.)


 What if you're dealing with a class? You'd need to deep copy the entire object
 for it to work. There's no way built into the language to do that (not to
 mention that it would be horrifically inefficient).

 - Jonathan M Davis


Eiffel does not do that either.
(even though it _does_ have a built in deep copy feature)

We don't have to over-engineer the feature, if somebody needs to 
deep-copy an object they can implement it themselves and use 
old(obj.deepCopy()).
Oct 16 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:


 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)
 
 We don't have to over-engineer the feature, if somebody needs to 
 deep-copy an object they can implement it themselves and use 
 old(obj.deepCopy()).


I agree. A shallow prestate is quite better than not having it at all in D.


taking a look.

Bye,
bearophile
Oct 16 2011
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 17-10-2011 02:43, bearophile wrote:

 Timon Gehr:


 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)

 We don't have to over-engineer the feature, if somebody needs to
 deep-copy an object they can implement it themselves and use
 old(obj.deepCopy()).


 I agree. A shallow prestate is quite better than not having it at all in D.


taking a look.

 Bye,
 bearophile


Just for the record, the documentation is at: 
http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf

I agree that having old would be great, even if without deep copying 

deep copying here.

- Alex
Oct 16 2011
parent reply Davidson Corry <davidsoncorry comcast.net> writes:
On 10/16/2011 9:35 PM, Alex Rønne Petersen wrote:

 On 17-10-2011 02:43, bearophile wrote:

 Timon Gehr:


 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)

 We don't have to over-engineer the feature, if somebody needs to
 deep-copy an object they can implement it themselves and use
 old(obj.deepCopy()).


 I agree. A shallow prestate is quite better than not having it at all
 in D.


 it's worth taking a look.

 Bye,
 bearophile


 Just for the record, the documentation is at:
 http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf


 I agree that having old would be great, even if without deep copying

 deep copying here.

 - Alex


Remember, efficiency is not the point, correctness is. Contract code 
goes away in the release build. (Arguably you might want to keep 
*preconditions* in library code, since they vet your input parameters. 
But in practice those usually go away in release builds as well, even in 
Eiffel.)

-- Dai
Oct 16 2011
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 17-10-2011 07:59, Davidson Corry wrote:

 On 10/16/2011 9:35 PM, Alex Rønne Petersen wrote:

 On 17-10-2011 02:43, bearophile wrote:

 Timon Gehr:


 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)

 We don't have to over-engineer the feature, if somebody needs to
 deep-copy an object they can implement it themselves and use
 old(obj.deepCopy()).


 I agree. A shallow prestate is quite better than not having it at all
 in D.


 it's worth taking a look.

 Bye,
 bearophile


 Just for the record, the documentation is at:
 http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf



 I agree that having old would be great, even if without deep copying

 deep copying here.

 - Alex


 Remember, efficiency is not the point, correctness is. Contract code
 goes away in the release build. (Arguably you might want to keep
 *preconditions* in library code, since they vet your input parameters.
 But in practice those usually go away in release builds as well, even in
 Eiffel.)

 -- Dai


Right, but you don't want your debug builds to be so slow that it makes 
you unproductive either. Either way, an initial lightweight old() would 
already be much better than having nothing. :)

- Alex
Oct 17 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 17, 2011 00:29:30 Timon Gehr wrote:

 On 10/16/2011 07:31 PM, Jonathan M Davis wrote:

 On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote:

 I don't agree that 'old' is very difficult to implement. Just evaluate
 what is inside the 'old' before you enter the in contract, store
 somewhere, maybe in hidden local variables, and make the data
 available
 in the out contract. Eiffel's 'old' does not do more than that.
 
 (but perhaps there are implementation details in DMD that make this
 more
 difficult than necessary. I don't know.)


 
 What if you're dealing with a class? You'd need to deep copy the entire
 object for it to work. There's no way built into the language to do
 that (not to mention that it would be horrifically inefficient).
 
 - Jonathan M Davis


 
 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)
 
 We don't have to over-engineer the feature, if somebody needs to
 deep-copy an object they can implement it themselves and use
 old(obj.deepCopy()).


I don't see how you could really expect to test the current state against the 
initial state when you don't actually save the initial state. And as far as 
implementing it yourself goes, you could go and do that that right now. You 
don't need compiler support to save the initial state somewhere and then test 
against it afterwards. It's just nicer if the compiler gives you support for 
it.

- Jonathan M Davis
Oct 16 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/17/2011 08:04 AM, Jonathan M Davis wrote:

 On Monday, October 17, 2011 00:29:30 Timon Gehr wrote:

 On 10/16/2011 07:31 PM, Jonathan M Davis wrote:

 On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote:

 I don't agree that 'old' is very difficult to implement. Just evaluate
 what is inside the 'old' before you enter the in contract, store
 somewhere, maybe in hidden local variables, and make the data
 available
 in the out contract. Eiffel's 'old' does not do more than that.

 (but perhaps there are implementation details in DMD that make this
 more
 difficult than necessary. I don't know.)


 What if you're dealing with a class? You'd need to deep copy the entire
 object for it to work. There's no way built into the language to do
 that (not to mention that it would be horrifically inefficient).

 - Jonathan M Davis


 Eiffel does not do that either.
 (even though it _does_ have a built in deep copy feature)

 We don't have to over-engineer the feature, if somebody needs to
 deep-copy an object they can implement it themselves and use
 old(obj.deepCopy()).


 I don't see how you could really expect to test the current state against the
 initial state when you don't actually save the initial state.


There are practical examples where this would be required but most of 
the time the tests are simple enough that the old expression can carry 
all the state you need. Remember that all implementations of DbC that 
have prestate (and I am aware of) don't perform a deep copy automatically.

Eg:

abstract class Set{
      property int size();
     bool contains(int x);
     void insert(int x)
       out{ assert( old(contains(x)) && size == old(size) ||
                   !old(contains(x)) && size == old(size)+1);
            assert(contains(old(x)));
            // possibly also require that everything that was
            // in the set before is still there
            [...]
       }
}




 And as far as
 implementing it yourself goes, you could go and do that that right now. You
 don't need compiler support to save the initial state somewhere and then test
 against it afterwards. It's just nicer if the compiler gives you support for
 it.

 - Jonathan M Davis


As far as implementing it myself goes I could even do contract 
programming in the brainF programming language. =)

The feature adds a lot of value to contract programming. I use contract 
programming occasionally and almost every contract I add eventually 
detects small bugs during the testing of new code parts.

BTW: "Somewhere" would have to be on the execution stack because the 
function could be recursive. There is no way to refer to variables 
defined in the in contract from the out contract and doing the saving at 
any other place than in a contract is not acceptable for obvious reasons.
Oct 17 2011