Difference between revisions of "Agent syntax"

m
m (Agent syntax)
 
Line 14: Line 14:
 
</e>
 
</e>
  
The reason to introduce a syntax like this is to let the compiler handle the correct type of the agent. Depending if the type system is enhanced on a per-declaration syntax - like the [[restrict types]] or the [[usage-site variance]] propose - then the definition of an agent can be very cumbersome. By giving the programmer a shorthand he does not need to specify the exact agent type himself.
+
The reason to introduce a syntax like this is to let the compiler handle the correct type of the agent. Depending if the type system is enhanced on a per-declaration syntax - like the [[restrict types]] or the [[usage-site variance]] proposals - then the definition of an agent can be very cumbersome. By giving the programmer a shorthand he does not need to specify the exact agent type himself.

Latest revision as of 11:23, 24 June 2007

Research: This page describes research about Eiffel, not the actual language specification.

Agent syntax

Idea: Use the like keyword followed by an agent signature definition to define agent types.

The good thing is that in Eiffel the "like" mechanism is already in place and well understood. In order to define an agent type something like

an_agent: like agent (a_x, a_y: INTEGER): BOOLEAN

would be very handy. Note that it is very similar to the definition of an inline agent. Of course the argument names could be omitted. But by allowing it we can even provide a named tuple as the argument signature for the call feature.

an_agent: like agent (INTEGER; INTEGER): BOOLEAN

The reason to introduce a syntax like this is to let the compiler handle the correct type of the agent. Depending if the type system is enhanced on a per-declaration syntax - like the restrict types or the usage-site variance proposals - then the definition of an agent can be very cumbersome. By giving the programmer a shorthand he does not need to specify the exact agent type himself.