eiffelroom - Agents - Comments

Thank you

zsimic — Fri, 26 Oct 2007 00:56:00 -0700

Thank you very much. That tool works very well. Fast and accurate.

Tool to convert

manus_eiffel — Fri, 19 Oct 2007 14:12:06 -0700

I've put a tool at http://eiffelstudio.origo.ethz.ch/download to update your classes to the new syntax.

Yes

zsimic — Wed, 17 Oct 2007 22:26:02 -0700

Voted 'yes' because I do have lots of code using ~, but I think it would be very easy to get rid of all those ~ notations quickly and painlessly.

Exposing pre/postconditions of agent

maverick — Thu, 02 Aug 2007 10:59:44 -0700

I disagree with the point that opposes exposing the preconditions and postconditions of agents. It seems to me like the only way to get complete specifications of higher order routines (somewhat related to higher order functions). In simpler terms, the postcondition function of agents may be used in postconditions of routines that receive agents as parameters (directly or indirectly) to describe the work in terms of the given agent.

If I bring the problem in a functional context, we can see what could be desirable for Eiffel. I'll use a lisp-like syntax and presume a design by contract macro set to make my example. Let specify the map function (for non-lispers: this function applies a given function to every elements of a list and returns a list containing the results).

(def-dbc-function (map f list)
  (require
    (not (null? f)))
  (deferred)
  (ensure
    (implies (not (null? list)) 
              (equal? result 
                      (cons (f (car list))
                            (map f (cdr list)))))
    (implies (null? list)
              (null? result))))

We can see a parallel with iterators in Eiffel. The main problem is that we cannot specify a procedure like do_all as we did map since it applies a procedure object and we do not know what we may call the frame of the operation. I think that's why no easy definition comes up for the postcondition feature of routines.

The only alternative is to write the loop as the implementation and the specification and then freeze the implementation. This is not quite convenient because there may be reasons to redefine it.

Simon

sometimes it's just a rubbish API

nenieorg — Mon, 30 Apr 2007 07:27:51 -0700

I'm not sure GUIs require a lot of these wrappers more than anything else, given a proper API. The poster child of wrapper agent in UI is the 'button clicked' usage pattern in EiffelVision where you have to give an agent taking 1827 parameters which are irrelevant to a button click. The correct API should take a parameterless procedure agent -- this is not incompatible with also having a fine grained API with more info for more sophisticated usage pattern of the mouse events, indeed the simple case can be implemented with a wrapper agent, but once and inside EiffelVision, rather than a lot everywhere in client ccode.

This does ring an alarm bell when the motivation for a language change is a defect in a library that can easily be fixed in the existing language, though I guess there remains some defensible use cases for dealing with wrapper agents.

Something like this may be needed, but there's inline agents

bmeyer — Thu, 26 Apr 2007 08:36:28 -0700

I agree that something like this would make life easier; many people have noted that the plain ? works only if you keep arguments in the order of the original.

I tend to like the ?n notation; the only immediate concern, barring further analysis, is that the semantics of the plain ? is not so obvious any more.

I think you can achieve the result almost as simply with inline agents, so I am not sure how critical this is. But it's definitely worth exploring.

Interesting

patrickr — Thu, 26 Apr 2007 08:12:45 -0700

That look's quite interesting, especially with GUI there are quite a lot of those wrappers and I think this would be a good way to simplify things.

Wiki

colin-adams — Thu, 12 Apr 2007 15:01:15 -0700

I know about it, and have contributed at least one page, and several comments. But I thought this was better as a blog entry.

Colin Adams

wiki wiki web

mtn — Thu, 12 Apr 2007 12:22:36 -0700

Hey Colin,

Did you know that we have developer wiki: http://eiffelsoftware.origo.ethz.ch/index.php/Main_Page

Some of your ideas would really fit good in there.

-- mTn-_-|

Agent Contracts

harrah — Thu, 12 Apr 2007 05:52:43 -0700

I agree that exposing and then explicitly checking pre/postconditions is not desirable, at least not as a general solution to agent contracts. Here are some thoughts on a possible form of a solution.

We have code that wants to call a feature that is bound at runtime. We may statically specify the type of feature (query or function) and the number, order, and type of open arguments that this feature must have.

However, we cannot statically guarantee to the client that binds a feature and gives it to our code anything more about those arguments. Neither can we describe what we expect from the feature.

So, we can currently write that we want the following entity:

to_call: PROCEDURE[TARGET_TYPE, TUPLE[argument_1: TYPE_1; ...]]

But, perhaps we want to write something more like

to_call: agent_interface prototype

(using 'agent_interface' as a keyword) for a feature `prototype' defined as:

prototype(argument_1: TYPE_1; ...)

         -- Defines the contract of an agent

      require

         precondition_1: ...

      agent_interface

      ensure

         precondition_2: ...

      end

The assignment

to_call := agent implementation

would require the feature `implementation' to effect `prototype' as if `prototype' were a feature inherited as deferred. That is, `implementation' would have to

Be a procedure with arguments that conform to the arguments of `prototype' (as is currently required)
Use assertion extensions (that is, 'require else' and 'ensure then')
Have a combined precondition and combined postcondition (like a redeclaration of a feature)

Additionally, I think there are some more details such as feature calls with `Current' as the target probably cannot or should not be allowed in the assertions of the interface.

An example following the previously provided DRAWABLE/SHAPE example:

to_do: agent_interface draw_shape

draw_shape(drawable: DRAWABLE; a_shape: SHAPE)

         -- Draw a shape on the given target.

      require

         a_shape_not_void: a_shape /= Void

         visible: drawable.is_visible

      deferred

      end

usage:

   drawable: DRAWABLE

   a_tower: SHAPE

   ...

   to_do := agent {DRAWABLE}.draw

   to_do.call([drawable, a_tower])

EDIT: corrected example usage

removing dynamic postconditions mitigates the problem but...

nenieorg — Wed, 11 Apr 2007 04:23:32 -0700

You can escape old and state issues by not having postconditions in the ROUTINE interface. There's no use case I can think of for checking postcondition explicitly at runtime (a failed postcondition can only be a bug), while there's a use case for checking some preconditions as part of establishing the client fulfills its side of the contract and takes remedial action otherwise.

Although even there is does get a bit fuzzy in that the only preconditions a client should be entitled to check is the preconditions which are part of the _static_ agent interface, for instance let's say we have a classic Eiffel pattern:

deferred class DRAWABLE

feature

    is_visible: BOOLEAN is

           -- Is drawable target ready to receive instructions?

        deferred

        end

    draw (a_shape: SHAPE) is

           -- Draw a shape on some target.

        require

           a_shape_not_void: a_shape /= Void

           visible: is_visible

        deferred

        end

end

which you would use as such:

drawable: DRAWABLE

...

  if drawable.is_visible then

     drawable.draw (a_tower)

  end

In agentified Eiffel the same pattern becomes:

drawable: ROUTINE [ANY, TUPLE [SHAPE]]

...

    -- (1) generic preconditions checking

   if drawable.preconditions_holds ([a_tower]) then

      drawable.call ([a_tower])

   end

    -- or (2) tagged preconditions checking

   if drawable.precondition_holds ("is_visible", [a_tower]) then

      drawable.call ([a_tower])

   end

Both patterns suffer from problems. (1) is checking too much, leaking debug code into non-debug execution flow. This illustrate the major drawback of exposing preconditions, it leaks the internal programming language plumbing inside the program. I think it has been a great strength of Eiffel to have fairly limited reflection facilities, so that you don't have "bits of compilers" leaking into programs, both conceptually and as part of the runtime footprint. This stuff is moving in the wrong direction.

(2) suffers a variant of the same problem, in that while semantically equivalent to the classic Eiffel pattern, it has also leaked compiler stuff into runtime, with some drawbacks for example the tag is a string, so there will be no compilation time error if is_visible is renamed etc, or if there's a typo in the first place, and the compiler cannot, or painfully, dead code away the 'debug' contracts that are always true in a correct program (and that damage extend to all routines with the same signature that are agent targets, and their descendants!). Also code analysis or automated verification becomes a harder problem.

I think its not only about

aleitner — Mon, 02 Apr 2007 06:13:46 -0700

I think its not only about the preservation. If you ask a routine whether a postcondition is satisfied, wich prestate and which poststate are you referring to? What is the meaning of `r.preconditions_hold ([1,2,3])'? Does it ask whether some past execution satisfied the postcondition, the last one, or maybe a hypthesized one?

I am not completely clear on it either, but at the moment the only thing that makes sense to me is to ask either:

1) Given this set of arguments, this prestate and this poststate, does the postcondition hold?

2) For the last execution of this agent, did the postcondition hold?

I think 1) is very tricky to implement. (What is a prestate and what is a poststate?) 2) is easier to implement, in fact it can be as simple as a variable. But in the end I am not sure about its usefulness, after all if the last execution failed I would have noticed because an exception was thrown. Btw, for 2) you don't need arguments either.

Andreas

Transmitting old values

colin-adams — Mon, 02 Apr 2007 02:16:51 -0700

As usual, I answered too quickly, before thinking.

I now see that preservation of old values across the call might be tricky (or not possible, for an implementation in Eiffel code). Colin Adams

Calling the implementation

colin-adams — Mon, 02 Apr 2007 02:02:26 -0700

By "calling the implementation", do you mean the implementation of the body or of the postcondition code?

I don't see where the difficulty lies. It works in workbench mode.

Colin Adams

Maybe I am missing

aleitner — Mon, 02 Apr 2007 01:32:17 -0700

Maybe I am missing something, but I still don't see how `postcondition_holds' can be implemented without calling the actual implementation? Or should the postcondition just be evaluated on the current state + arguments? If so, how can a `postcondition_holds' ever ealuate to True for a postcondition like `count = old count + 1'?