www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Contract programming syntax

reply bearophile <bearophileHUGS lycos.com> writes:
I like contract programming, it helps me avoid bugs. This is an example from
the docs:

long squareRoot(long x)
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    body {
        return cast(long)std.math.sqrt(cast(real)x);
    }


But isn't a syntax like the following better? To me it looks more logic,
because in{} and out(){} are part of the function, and there's no need of a
special syntax for the body (and the 'body' keyword):

long squareRoot(long x) {
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    return cast(long)std.math.sqrt(cast(real)x);
}

Bye,
bearophile
Apr 08 2009
next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 I like contract programming, it helps me avoid bugs. This is an example from
the docs:
 
 long squareRoot(long x)
     in {
         assert(x >= 0);
     }
 
     out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
 
     body {
         return cast(long)std.math.sqrt(cast(real)x);
     }
 
 
 But isn't a syntax like the following better? To me it looks more logic,
because in{} and out(){} are part of the function, and there's no need of a
special syntax for the body (and the 'body' keyword):
 
 long squareRoot(long x) {
     in {
         assert(x >= 0);
     }
 
     out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
 
     return cast(long)std.math.sqrt(cast(real)x);
 }
 
 Bye,
 bearophile
I agree, the 'body' keyword is the most useless thing in the language. I find it makes functions much harder to read. I hate my body.
Apr 08 2009
parent reply Kagamin <spam here.lot> writes:
Don Wrote:

 I agree, the 'body' keyword is the most useless thing in the language. I 
 find it makes functions much harder to read.
 I hate my body.
I second this.
Apr 08 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin <spam here.lot> wrote:

 Don Wrote:

 I agree, the 'body' keyword is the most useless thing in the language. I
 find it makes functions much harder to read.
 I hate my body.
I second this.
Thirded.
Apr 08 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
 Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin <spam here.lot> wrote:

 Don Wrote:

 I agree, the 'body' keyword is the most useless thing in the language. I
 find it makes functions much harder to read.
 I hate my body.
I second this.
Thirded.
Fourthed. I also can't tell you how many times I wanted to use 'body' as a variable name :|
Apr 08 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Jarrett Billingsley wrote:
  Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin <spam here.lot> wrote:

 Don Wrote:

 I agree, the 'body' keyword is the most useless thing in the language. I
 find it makes functions much harder to read.
 I hate my body.
I second this.
Thirded.
Fourthed. I also can't tell you how many times I wanted to use 'body' as a variable name :|
Call me a sheep, but... Fifthed. (is that even a word? :P)
Apr 08 2009
prev sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Jarrett Billingsley wrote:
  Wed, Apr 8, 2009 at 1:02 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Wed, 08 Apr 2009 20:01:46 +0400, Kagamin <spam here.lot> wrote:

 Don Wrote:

 I agree, the 'body' keyword is the most useless thing in the language. I
 find it makes functions much harder to read.
 I hate my body.
I second this.
Thirded.
Fourthed. I also can't tell you how many times I wanted to use 'body' as a variable name :|
Fifthed. How about using bigfloat for that?
Apr 08 2009
parent reply "Danny Wilson" <bluezenix gmail.com> writes:
2 x Fifthed + 1 = Eleventhed!

Op Wed, 08 Apr 2009 20:51:17 +0200 schreef Alexander Pánek  
<alexander.panek brainsware.org>:


 Fifthed. How about using bigfloat for that?
Apr 08 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Danny Wilson wrote:
 2 x Fifthed + 1 = Eleventhed!
Don't you mean 2 × Fifthed + Firsted = Eleventhed ? Stewart.
Apr 09 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gridbr$mv4$1 digitalmars.com...
I like contract programming, it helps me avoid bugs. This is an example 
from the docs:

 long squareRoot(long x)
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    body {
        return cast(long)std.math.sqrt(cast(real)x);
    }


 But isn't a syntax like the following better? To me it looks more logic, 
 because in{} and out(){} are part of the function, and there's no need of 
 a special syntax for the body (and the 'body' keyword):

 long squareRoot(long x) {
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    return cast(long)std.math.sqrt(cast(real)x);
 }

 Bye,
 bearophile
This is one of those things that has always kinda bugged me about the language, but I never really considered a big enough deal to bring up. But now that it has been brought up: Yes, I agree completely.
Apr 08 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
More agreement here.

--bb

On Thu, Apr 9, 2009 at 2:41 AM, Nick Sabalausky <a a.a> wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gridbr$mv4$1 digitalmars.com...
I like contract programming, it helps me avoid bugs. This is an example
from the docs:

 long squareRoot(long x)
 =A0 =A0in {
 =A0 =A0 =A0 =A0assert(x >=3D 0);
 =A0 =A0}

 =A0 =A0out (result) {
 =A0 =A0 =A0 =A0assert((result * result) <=3D x && (result+1) * (result+1=
) >=3D x);
 =A0 =A0}

 =A0 =A0body {
 =A0 =A0 =A0 =A0return cast(long)std.math.sqrt(cast(real)x);
 =A0 =A0}


 But isn't a syntax like the following better? To me it looks more logic,
 because in{} and out(){} are part of the function, and there's no need o=
f
 a special syntax for the body (and the 'body' keyword):

 long squareRoot(long x) {
 =A0 =A0in {
 =A0 =A0 =A0 =A0assert(x >=3D 0);
 =A0 =A0}

 =A0 =A0out (result) {
 =A0 =A0 =A0 =A0assert((result * result) <=3D x && (result+1) * (result+1=
) >=3D x);
 =A0 =A0}

 =A0 =A0return cast(long)std.math.sqrt(cast(real)x);
 }

 Bye,
 bearophile
This is one of those things that has always kinda bugged me about the language, but I never really considered a big enough deal to bring up. Bu=
t
 now that it has been brought up: Yes, I agree completely.
Apr 08 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gridbr$mv4$1 digitalmars.com...
I like contract programming, it helps me avoid bugs. This is an example
from the docs:

 long squareRoot(long x)
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    body {
        return cast(long)std.math.sqrt(cast(real)x);
    }


 But isn't a syntax like the following better? To me it looks more logic,
 because in{} and out(){} are part of the function, and there's no need of
 a special syntax for the body (and the 'body' keyword):

 long squareRoot(long x) {
    in {
        assert(x >= 0);
    }

    out (result) {
        assert((result * result) <= x && (result+1) * (result+1) >= x);
    }

    return cast(long)std.math.sqrt(cast(real)x);
 }

 Bye,
 bearophile
This is one of those things that has always kinda bugged me about the language, but I never really considered a big enough deal to bring up. But now that it has been brought up: Yes, I agree completely.
while(oldContractSyntaxSucks) { // Currently evaluates to true. vote++; }
Apr 08 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
dsimcha wrote:
 while(oldContractSyntaxSucks) {  // Currently evaluates to true.
     vote++;
 }
And always will do :D Proposed updated code: ---- while(currentContractSyntaxSucks) { // Currently evaluates to true. vote++; } complainAboutSomethingElse(); ----
Apr 08 2009
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:
 But isn't a syntax like the following better? To me it looks more logic,
because in{} and out(){} are part of the function, and there's no need of a
special syntax for the body (and the 'body' keyword):
 
 long squareRoot(long x) {
     in {
         assert(x >= 0);
     }
 
     out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
 
     return cast(long)std.math.sqrt(cast(real)x);
 }
No. This proposed syntax change is quite misleading. Contracts cannot access the function's local variables, but it looks like they can. Contracts are executed at particular times, but that syntax makes them look like they execute wherever they are written. I believe you can put "body" before each function body, even with no contracts, if it makes you happier.
 Bye,
 bearophile
Apr 08 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright <dhasenan gmail.com> wrote:
 No. This proposed syntax change is quite misleading. Contracts cannot access
 the function's local variables, but it looks like they can. Contracts are
 executed at particular times, but that syntax makes them look like they
 execute wherever they are written.

 I believe you can put "body" before each function body, even with no
 contracts, if it makes you happier.
OK, then what about: void foo() in { ... } out { ... } { ... } the 'body' keyword is completely arbitrary. There is no ambiguity here. Also, I almost never use contracts because of their verbosity. It's much shorter - and functionally equivalent - to just put asserts in the function body, some at the beginning and some in a scope(exit).
Apr 08 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:
 On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright <dhasenan gmail.com> wrote:
 No. This proposed syntax change is quite misleading. Contracts cannot access
 the function's local variables, but it looks like they can. Contracts are
 executed at particular times, but that syntax makes them look like they
 execute wherever they are written.

 I believe you can put "body" before each function body, even with no
 contracts, if it makes you happier.
OK, then what about: void foo() in { ... } out { ... } { ... } the 'body' keyword is completely arbitrary. There is no ambiguity here.
Agreed.
 Also, I almost never use contracts because of their verbosity.  It's
 much shorter - and functionally equivalent - to just put asserts in
 the function body, some at the beginning and some in a scope(exit).
Not technically true -- contract can contain more than raw asserts. For example, it might contain a non-trivial loop (such as a foreach which calls a virtual opApply) which may be hard for the compiler to optimize out even if it can deduce the body is a no-op (because it only contained assertions, most likely).
Apr 08 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Apr 8, 2009 at 5:32 PM, Frits van Bommel
<fvbommel remwovexcapss.nl> wrote:
 Not technically true -- contract can contain more than raw asserts.
 For example, it might contain a non-trivial loop (such as a foreach which
 calls a virtual opApply) which may be hard for the compiler to optimize out
 even if it can deduce the body is a no-op (because it only contained
 assertions, most likely).
Sure, but most of my contracts are composed entirely of asserts. And there's always the debug{} block.
Apr 08 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:
 On Wed, Apr 8, 2009 at 4:51 PM, Christopher Wright <dhasenan gmail.com> wrote:
 No. This proposed syntax change is quite misleading. Contracts cannot access
 the function's local variables, but it looks like they can. Contracts are
 executed at particular times, but that syntax makes them look like they
 execute wherever they are written.

 I believe you can put "body" before each function body, even with no
 contracts, if it makes you happier.
OK, then what about: void foo() in { ... } out { ... } { ... }
I wouldn't mind that terribly.
 the 'body' keyword is completely arbitrary.  There is no ambiguity here.
 
 Also, I almost never use contracts because of their verbosity.  It's
 much shorter - and functionally equivalent - to just put asserts in
 the function body, some at the beginning and some in a scope(exit).
I use them with some frequency. I find their overhead to be minimal.
Apr 08 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 09 Apr 2009 00:51:49 +0400, Christopher Wright <dhasenan gmail.com>
wrote:

 bearophile wrote:
 But isn't a syntax like the following better? To me it looks more  
 logic, because in{} and out(){} are part of the function, and there's  
 no need of a special syntax for the body (and the 'body' keyword):
  long squareRoot(long x) {
     in {
         assert(x >= 0);
     }
      out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
      return cast(long)std.math.sqrt(cast(real)x);
 }
No. This proposed syntax change is quite misleading. Contracts cannot access the function's local variables, but it looks like they can. Contracts are executed at particular times, but that syntax makes them look like they execute wherever they are written. I believe you can put "body" before each function body, even with no contracts, if it makes you happier.
 Bye,
 bearophile
Does scope(exit) also make you feel that it is executed immediately? I see nothing wrong with local variables to be available in "out", but in most cases "out" is defined /before/ function body so no variables will be visible this way. It also looks like you can have multiple in{} and out{} sections this way. This is a nice bonus, btw!
Apr 08 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Denis Koroskin wrote:
 On Thu, 09 Apr 2009 00:51:49 +0400, Christopher Wright 
 <dhasenan gmail.com> wrote:
 
 bearophile wrote:
 But isn't a syntax like the following better? To me it looks more 
 logic, because in{} and out(){} are part of the function, and there's 
 no need of a special syntax for the body (and the 'body' keyword):
  long squareRoot(long x) {
     in {
         assert(x >= 0);
     }
      out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
      return cast(long)std.math.sqrt(cast(real)x);
 }
No. This proposed syntax change is quite misleading. Contracts cannot access the function's local variables, but it looks like they can. Contracts are executed at particular times, but that syntax makes them look like they execute wherever they are written. I believe you can put "body" before each function body, even with no contracts, if it makes you happier.
 Bye,
 bearophile
Does scope(exit) also make you feel that it is executed immediately?
Well, take this example: void foo(int i) { if (i < 0) return; scope (exit) logExit; } The position has meaning here. Then take this example: void foo(int i) { if (i < 0) return; in { assert (i != -1; } } This is confusing. Good style dictates that your contracts should be separated from the body of your function, though. The bigger issue is the apparent nesting of scopes.
Apr 08 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Apr 8, 2009 at 6:38 PM, Christopher Wright <dhasenan gmail.com> wro=
te:

 Then take this example:

 void foo(int i)
 {
 =A0 if (i < 0) return;
 =A0 in { assert (i !=3D -1; }
 }

 This is confusing.
There's a simple solution: define the function body grammar to only allow in{} and out{} blocks at the beginning of the function, before any statements.
Apr 08 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:
 On Wed, Apr 8, 2009 at 6:38 PM, Christopher Wright <dhasenan gmail.com> wrote:
 
 Then take this example:

 void foo(int i)
 {
   if (i < 0) return;
   in { assert (i != -1; }
 }

 This is confusing.
There's a simple solution: define the function body grammar to only allow in{} and out{} blocks at the beginning of the function, before any statements.
Or just your style guide. But even if you can demonstrate significant benefits (and I don't see any benefits, really), inertia is against you. I don't think Walter would change it for anything but extreme provocation.
Apr 08 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright <dhasenan gmail.com> wrote:
 Or just your style guide. But even if you can demonstrate significant
 benefits (and I don't see any benefits, really), inertia is against you. I
 don't think Walter would change it for anything but extreme provocation.
Are you suggesting an "offer he can't refuse"? ;)
Apr 08 2009
parent reply Don <nospam nospam.com> writes:
Jarrett Billingsley wrote:
 On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright <dhasenan gmail.com> wrote:
 Or just your style guide. But even if you can demonstrate significant
 benefits (and I don't see any benefits, really), inertia is against you. I
 don't think Walter would change it for anything but extreme provocation.
Are you suggesting an "offer he can't refuse"? ;)
With the pressure to reduce the number of keywords in D, body is the most obvious candidate. It's identical to /*body*/ as far as I can tell.
Apr 08 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Apr 9, 2009 at 2:56 AM, Don <nospam nospam.com> wrote:
 Jarrett Billingsley wrote:
 On Wed, Apr 8, 2009 at 10:59 PM, Christopher Wright <dhasenan gmail.com>
 wrote:
 Or just your style guide. But even if you can demonstrate significant
 benefits (and I don't see any benefits, really), inertia is against you=
.
 I
 don't think Walter would change it for anything but extreme provocation=
.
 Are you suggesting an "offer he can't refuse"? =A0;)
With the pressure to reduce the number of keywords in D, body is the most obvious candidate. It's identical to /*body*/ as far as I can tell.
Oh. I was kind of thinking a horse head in his bed.
Apr 09 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Christopher Wright:
Contracts cannot access the function's local variables, but it looks like they
can.<
You are right, thank you. Bye, bearophile
Apr 08 2009
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 08 Apr 2009 10:46:19 -0400, bearophile wrote:

 But isn't a syntax like the following better? To me it looks more logic,
 because in{} and out(){} are part of the function, and there's no need 
 of a special syntax for the body (and the 'body' keyword):
Yes! I've never been happen with the awkwardness of the current syntax. It looks just plain wrong and certainly not intuitive or helpful when reading code. And as you suggest 'in' and 'out' are already special words (and Walter has a special love for overloading keywords) so 'body' isn't needed in your suggestion. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Apr 08 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-04-08 10:46:19 -0400, bearophile <bearophileHUGS lycos.com> said:

 I like contract programming, it helps me avoid bugs. This is an example 
 from the docs:
 
 long squareRoot(long x)
     in {
         assert(x >= 0);
     }
 
     out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
 
     body {
         return cast(long)std.math.sqrt(cast(real)x);
     }
 
 But isn't a syntax like the following better?
 To me it looks more logic, because in{} and out(){} are part of the 
 function, and there's no need of a special syntax for the body (and the 
 'body' keyword):
 
 long squareRoot(long x) {
     in {
         assert(x >= 0);
     }
 
     out (result) {
         assert((result * result) <= x && (result+1) * (result+1) >= x);
     }
 
     return cast(long)std.math.sqrt(cast(real)x);
 }
I believe the syntax should make the contracts part of the function signature, not part of the function body, because contracts are about expressing the function's interface. So I disagree with your proposed syntax which puts the contracts as part of the body. I do agree however that reserving 'body' as a keyword is from time to time hindering. I'd certainly welcome a change if it allows removing 'body' as a keyword. But not this one, because it puts the contract at the wrong place. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Apr 08 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Michel Fortin wrote:
<snip>
 I believe the syntax should make the contracts part of the function 
 signature, not part of the function body, because contracts are about 
 expressing the function's interface. So I disagree with your proposed 
 syntax which puts the contracts as part of the body.
<snip> Finally, a counter-argument with which I agree. Moreover, having in/out contracts as part of the function body suggests that they are part of what is overridden. But the language doesn't quite work like that. http://d.puremagic.com/issues/show_bug.cgi?id=302 http://www.digitalmars.com/d/archives/digitalmars/D/31595.html Moreover, it ought to be possible to put contracts on abstract or interface methods. This wouldn't fit in with contracts being in the body. Stewart.
Apr 09 2009
parent Kagamin <spam here.lot> writes:
Stewart Gordon Wrote:

 Finally, a counter-argument with which I agree.  Moreover, having in/out 
 contracts as part of the function body suggests that they are part of 
 what is overridden.  But the language doesn't quite work like that.
I thought, they're overriden.
Apr 09 2009
prev sibling parent reply Tomasz Sowi&#324;ski <tomeksowi.remove.this gmail.and.this.com> writes:
Jarrett Billingsley Wrote:

 OK, then what about:
 
 void foo()
 in { ... }
 out { ... }
 { ... }
 
 the 'body' keyword is completely arbitrary.  There is no ambiguity here.
 
 Also, I almost never use contracts because of their verbosity.  It's
 much shorter - and functionally equivalent - to just put asserts in
 the function body, some at the beginning and some in a scope(exit).
I like removing "body". But maybe we can make contracts a bit nicer by removing braces if the contract contains only one statement: void foo() in assert(something); out assert(something_else); { ... } would that be ambiguous to the compiler? Tomek
Apr 09 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:

<snip>
 I like removing "body". But maybe we can make contracts a bit nicer by
removing braces if the contract contains only one statement:
 
 void foo()
 in assert(something);
 out assert(something_else);
 { ... }
 
 would that be ambiguous to the compiler?
Probably not, but I'm not sure I like it at all. Firstly, it reminds me of the old crocky C syntax for declaring parameter types. Secondly, if we're going to allow contracts on abstract/interface functions, would you need to write two semicolons in a row with this syntax? (Maybe there's no need for a semicolon in lieu of the body in such cases. It's just what the compiler used to allow, though it never actually did anything with the contracts.) Stewart.
Apr 09 2009