Communicating between in and out contracts

[Michel Fortin]

On 2009-10-20 12:04:20 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Tue, 20 Oct 2009 11:57:05 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> On 2009-10-20 11:44:00 -0400, "Steven Schveighoffer"  
>> <schveiguy at yahoo.com> said:
>> 
>>> On Tue, 20 Oct 2009 08:36:14 -0400, Michel Fortin   
>>> <michel.fortin at michelf.com> wrote:
>>> 
>>>> On 2009-10-20 08:16:01 -0400, "Steven Schveighoffer"   
>>>> <schveiguy at yahoo.com> said:
>>>> 
>>>>> Incidentally, shouldn't all access to the object in the in contract  be 
>>>>>   const by default anyways?
>>>>  Hum, access to everything (including global variables, arguments),  
>>>> not  just the object, should be const in a contract. That might be  
>>>> harder to  implement though.
>>>  Yeah, you are probably right.  Of course, a const function can still  
>>> alter  global state, but if you strictly disallowed altering global  
>>> state, we are  left with only pure functions (and I think that's a  
>>> little harsh).
>> 
>> Not exactly. Pure functions can't even read global state (so their  
>> result can't depend on anything but their arguments), but it makes  
>> perfect sense to read global state in a contract. What you really need  
>> is to have a const view of the global state. And this could apply to 
>> all  asserts too.
> 
> Yes, but what I'm talking about is "what functions can you call while 
> in a  contract."  Access to data should be const as you say.  But if 
> you follow  that logic to the most strict interpretation, the only 
> "safe" functions to  allow are pure functions.
> 
> i.e.:
> 
> int x;
> 
> class C
> {
>    void foo()
>    in
>    {
>      x = 5; // I agree this should be an error
>      bar(); // ok?
>    }
>    {}
> 
>    void bar() const
>    {
>      x = 5;
>    }
> }

When you try to write to x yes it's an error. But if you were reading x 
it should not be an error. Basically inside the contract a global like 
x should be seen as const(int) just like the object should be seen as 
const(C).

Pure functions are somewhat alike, but are more restrictive since you 
can only access immutable globals. So what we need is semi-pure 
functions that can see all the globals as const data, or in other terms 
having no side effect but which can be affected by their environment. 
Another function qualifier, isn't it great! :-)


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/