Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE

by Helmut Brandl (modified: 2010 Mar 02)

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
  • Zoran Simic (14 years ago 3/3/2010)

    Agreed

    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...

    • Colin Adams (14 years ago 3/3/2010)

      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.

  • Manu (14 years ago 3/3/2010)

    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.