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?