Formal Generics in ROUTINE, PROCEDURE, FUNCTION and PREDICATE
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?
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...
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 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 naturallyTYPE [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 forBASE_TYPE .