blogFormal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE

Posted March 2nd, 2010 by Helmut Brandl
in

There are 4 deferred classes defined in ELKS to represent agents 

  ROUTINE  [BASE_TYPE, OPEN_ARGS->TUPLE]
  PROCEDURE[BASE_TYPE, OPEN_ARGS->TUPLE]   
  FUNCTION [BASE_TYPE, OPEN_ARGS->TUPLE, RESULT_TYPE]
  PREDICATE[BASE_TYPE, OPEN_ARGS->TUPLE]


The OPEN_ARGS is tuple to represent the tuple of arguments which need to be provided at call time. In case of FUNCTION, RESULT_TYPE is the type of the result returned by the query.

The first formal generic BASE_TYPE seems to be completely unnecessary. Clearly, each agent represents a feature of a certain type. But that type is not needed in the abstraction.

All routines in the standard library, which expect an agent as argument use as BASE_TYE the universal type ANY.

It is difficult to imagine that it makes sense to restrict the base type of an agent to be a descendant of a certain other type. The feature expecting a procedure or function as argument should work with any procedure/function which has a compatible signature. The only thing it does is call it.

Wouldn't it be more consisten to remove the formal generic BASE_TYPE from the above abstractions?

Comments

Agreed

zsimic's picture
Submitted by Zoran Simic on Wed, 03/03/2010 - 04:34.

I can attest that the BASE_TYPE generic is never used. I have never seen even one case where the base type was restricted to anything...

I once used it as a kind of

colin-adams's picture
Submitted by colin adams on Wed, 03/03/2010 - 05:11.

I once used it as a kind of documentation. I created a deferred class with a function in it, and specified the contract of the function (it was intended as a call back) there. The idea was that the programmer, seeing a BASE_TYPE, would take a look at that class, and know what the contract of the call-back was supposed to be.

This could only act as a hint. I was just trying to make some use of an otherwise useless construct.

It is a connection between

manus_eiffel's picture
Submitted by Emmanuel Stapf on Wed, 03/03/2010 - 06:53.

It is a connection between TYPE being generic and the SCOOP necessity to know the separate status of the target type. A new query was added to ROUTINE to get that type and the signature of that query was naturally TYPE [BASE_TYPE]. If we did not have BASE_TYPE then the only type we could give that query was TYPE [detachable ANY].

However I don't know about the current version of SCOOP and if this still applies.

Others from the ECMA committee might remember another reason for BASE_TYPE.

Syndicate content