I think the reason you keep saying has-a is that you're using conses as an example. A cons does has-a car and has-a cdr, but this is too restrictive. For example, say you wanted to make a type that acts like a list, that is, it supports map, each, reduce, all, rev, some, len, nthcdr, and so on.
arc> (= a (my-listtype 'foo nil t 'bar))
(foo nil t bar)
arc> (car a) ; has-a car
foo
arc> (cdr a) ; has-a cdr
(nil t bar)
arc> (map no a) ; has-a map (?!)
(nil t nil nil)
arc> (rev a) ; has-a rev (?!)
(bar t nil foo)
arc> (some no a) ; has-a some (?!)
t
arc> (all no a) ; has-a all (?!)
nil
See what I mean? (Note: I fully agree that it would be really cool if the above actually worked, I'm just arguing that the name has-a makes no sense here.)
has-a scanner interface just means that: it has-a car and has-a cdr. 'map et al. now require an object which has-a scanner interface, and will simply use basic 'car and 'cdr operations to work. This supports genericity: just write 'map et al once, then any new type you create just needs to give 'car and 'cdr, and say it has-a scanner interface, and the existing map will work.
Now suppose we have another type, which has-a 'collide function, which handles the events where it is collided with in the game space. A ship has-a collide function, and the basic collission detection code is something like this:
(thread
(while t
((afn (game-elements)
(iflet (first . rest) game-elements
(each e rest
(when (overlapping first e)
(collide first) (collide e))))
game-elements)))
The above now works on ships. Now suppose we add a new type of game element: a missile. We simply define its 'collide function, and declare it as having that function; now it magically works without changing the collision-detecting code.
