• chris jones (29/29) Oct 13 2002 It seems to me the syntax is inconsistent with the rest of the language....
• Russ Lewis (19/23) Oct 13 2002 I hear you, but in my view, Walter's syntax is better. I see a function...
• Evan McClanahan (19/42) Oct 14 2002 I suppose that it would be most logical to make them look like this:

"chris jones" <flak clara.co.uk> writes:

It seems to me the syntax is inconsistent with the rest of the language. The
contracts belong to the function but are not enclosed in a block as all
other code is. I think the function brakets should enclose the contracts
somthing like this....

long square_root(long x)
{
in
  {
  assert(x >= 0);
  }
out (result)
  {
  assert((result * result) == x);
  }
return math.sqrt(x);
}

Its one less keyword to worry about :) Or mabey like this...
long square_root(long x)
{in
  {
  assert(x >= 0);
  }
out (result)
  {
  assert((result * result) == x);
  }
body  {  return math.sqrt(x);  }
}
easier to read but more typing.chris

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

chris jones wrote:

 It seems to me the syntax is inconsistent with the rest of the language. The
 contracts belong to the function but are not enclosed in a block as all
 other code is. I think the function brakets should enclose the contracts
 somthing like this....

I hear you, but in my view, Walter's syntax is better.  I see a function as two
things:
   1) A declaration that determines its interface with the other parts of the
program
   2) An internal implementation

IMHO, the contracts are parts of the interface, just like the function argument
types and return type are.  Hopefully, we will eventually have compilers that
will be able to check these contracts pretty thoroughly at runtime.  Compilers
already tell us that a certain set of arguments isn't valid; I want compiler to
also tell us, at compile time, that the arguments we pass to a function are
invalid.  Likewise, I want the compiler to tell us that a certain function is
obviously in error because it cannot fulfill its out conditions, just like
current compilers tell you "function must return a value" and such.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Russ Lewis wrote:
 chris jones wrote:
 
 
It seems to me the syntax is inconsistent with the rest of the language. The
contracts belong to the function but are not enclosed in a block as all
other code is. I think the function brakets should enclose the contracts
somthing like this....

 
 
 I hear you, but in my view, Walter's syntax is better.  I see a function as two
 things:
    1) A declaration that determines its interface with the other parts of the
 program
    2) An internal implementation
 
 IMHO, the contracts are parts of the interface, just like the function argument
 types and return type are.  Hopefully, we will eventually have compilers that
 will be able to check these contracts pretty thoroughly at runtime.  Compilers
 already tell us that a certain set of arguments isn't valid; I want compiler to
 also tell us, at compile time, that the arguments we pass to a function are
 invalid.  Likewise, I want the compiler to tell us that a certain function is
 obviously in error because it cannot fulfill its out conditions, just like
 current compilers tell you "function must return a value" and such.

I suppose that it would be most logical to make them look like this:

in
{
     ...tests...
}
uint myfunc(..args..)
{
     ...code...
}
out (result)
{
     ...more tests...
}

since it doesn't ugly up the function body, and gives you a real idea of 
that's going to happen about the order in which these tests are 
executed.  Whether or not you like it, it would be cool if it were an 
option syntactically.

Evan