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

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))) ]

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