Sequence functions should be removed from code for computing discriminating functions

[robert-strandh]

Currently, the code for computing discriminating functions calls some sequence functions, and some other functions (like EVERY) that may be implemented as generic functions in SICL. It would not be a problem if the user could not add methods on any of those functions (because then satiation would fix the problem), but now I am thinking that it ought to be possible to add methods on some of these functions. If such a function is used in computing discriminating functions, then its discriminating function could not be computed. The solution is to replace the use of these functions in code for computing discriminating functions by simpler functions that are not likely to be implemented as generic functions. For example MEMBER could be used in place of FIND.

[marcoheisig]

This problem shouldn't occur because the sequence functions are sealable generic functions that have been sealed on the domain of lists and vectors. New methods can only be added, modified, or removed if their domain doesn't intersect with any of the sealed domains.

The only potentially problematic step is loading the library into SICL in the first place. I haven't given that much thought so far.

[Bike]

Edited your comment to fix the linebreaks, hope you don't mind.

Given that in the context of computing discriminating functions, the arguments to sequence functions should be of known type (probably all lists), it would seem more elegant to me to just use versions that won't be affected by further method definition. Like, have the compiler replace calls to the generic function in the source with calls to specific versions.