gilad%cs.utah.edu@wasatch.UUCP (Gilad Bracha) (03/11/89)
From article <112@eiffel.UUCP> > We would like to apply routines on sets of objects, but there seems to > have problems with types. [We would like to write:] > > class A > feature > > set_do_all (action : X) is > do > from set.start > until set.offright > loop > set.value.action; > set.forth; > end; > end ; -- set_do_all > > end; -- class A > > Our problem here is to determine what is X (the type of action). Is there > a type "routine" ? If not, we cannot define such a routine. In article <114@eiffel.UUCP>, Bertrand Meyer proposes a solution, using a combination of deferred classes and constrained genericity. The solution proposed is inadequate. It requires us to define a special class for every function of every type we might want to use over a list (or set, or whatever structure). We would have to have classes for INTEGERs with action SQR, INTEGERs with action CUBE, INTEGERs with action SQRT, etc. And then we would need classes for BOOLEANs with action NOT, LISTs with action LENGTH etc. The question is really whether there is a way to abstract over routines. As another example, suppose we wish to define a MAP function, roughly like mapcar in LISP. That is, MAP accepts a particular function, and performs it on all the elements of the list, returning a new list of results. Given a list (1,2,3,4) and a function SQR(X:INTEGER) is do Result := X^2 end the result should be (1,4,9,16). MAP depends only on the structure of lists, not on their contents and presumably should be included in a class LIST[T]. According to OOSC, Eiffel does not have a type "routine", or in other words, routines are not first-class values in the language. So there is no way to express the type of MAP, and thus, no way to express MAP at all. A philosophical question arises here - do we want such abstractions at all ? OOSC argues that we do not want to specify systems in terms of one particular functionality. But it seems that at this level of generality, the arguments presented against functional definitions are irrelevant - this is not an application that will change or evolve, but a general purpose feature of lists. So the question is, should Eiffel be extended with first-class routines, or should a more restricted mechanism (like iterators in CLU) be used. Gilad Bracha Gilad