liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] Closures


From: Paolo Redaelli
Subject: Re: [Liberty-eiffel] Closures
Date: Wed, 20 Nov 2013 09:10:33 +0100

Yesterday I was going to instinctively answer that we should strive to eradicate side effects, as I was always convinced that "side effects are evil (TM)".
AFAIK correct design in fact requires that any query should never ever change the state of its Current object, i.e. the follow should always hold

local a_foo, old_foo: FOO
old_foo := a_foo.deep_twin
my_x := a_foo.x
check
  a_foo.is_deep_equal(old_foo)
end

Note that I'm now not sure if it this should hold with twin and is_equal instead of their deep counterparts.

I'm aware that most code does not try to adhere to this rule; even more the compiler's parser itself heavily rely on side-effects of its query to achieve good performance with a reasonable low memory occupation.

Of course adding a "--side-effects-are-errors" flag is a really difficult task, for a release around Terzaghi I would jokingly say...

If I recall correctly I read about the side-effect-free rule in Meyer's "Object Oriented Software Construction" and I accepted it almost as a matter of faith but of course CS and IT are not a matter of faith. Is there any "sound", Eiffellish argument against this rule?




2013/11/20 Cyril ADRIAN <address@hidden>
Hi,

The rationale is that it is the role of the outside feature to initialize its local variables; but on the other hand it must be able to delegate some computation to inline agents. If you forbid side effects, how would the inline agent be able to communicate with its outside feature?

I try and look beyond mere sequential programs (SCOOP is always lurking somewhere). Assigning to a variable is not thread-safe, but side effects are safe if SCOOP locking rules are respected. But that's a future story (not before curtiss or even beyond) ;-)

I'm not even sure I should allow post-assignment to outside locals (see TEST_CLOSURE02). I allow it because the inline agent has not yet been called (but that is not checked by the compiler).

The line is hard to draw.

Cheers,

Cyril ADRIAN (from office)
To any NSA and FBI agents reading my email: please consider whether defending the US Constitution against all enemies, foreign or domestic, requires you to follow Snowden's example. 



2013/11/19 Raphael Mack <address@hidden>
Hi,

oh Cyril, you're so great!

In the wiki you wrote:
"access is read-only: you cannot assign to an outside local variable
(and, of course, to an argument, but that's standard Eiffel anyway)"

What is the rational for this? - I like the rule, but when we have it,
wouldn't it be inline to also forbid feature calls with (observable)
side effect on the outer variables? - Yes, we do not have a concept of
"pure" features in Liberty, but may be we would like to have it once? Or
now?

Cheers,
Rapha

On Di, 2013-11-19 at 15:59 +0100, Cyril ADRIAN wrote:
> All,
>
>
> I started Bell implementations, esp. inline agents as closures.
>
>
> Of course, the work is only begun. It currently lies only in my public
> Github repo and is not pushed in Savannah yet.
>
>
> I also added a little explanation of what I intend to do in the wiki.
> See: http://wiki.liberty-eiffel.org/index.php/Agent#Inline_agents
>
> Feel free to comment.
>
> Cheers,
>
> Cyril ADRIAN (from office)
> To any NSA and FBI agents reading my email: please consider whether
> defending the US Constitution against all enemies, foreign or
> domestic, requires you to follow Snowden's example.
>
>
> Google+ Posts
> My latest G+: Liberty Eiffel
> adler-rc1 is out!
> My G+ - Posts - Add to Circles -
> 21:01 Nov-05
>   Get this email app!
>
> Get a signature like this. CLICK HERE.
>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]