To be pedantic, it was proven that any program can be expressed in one line of APL (two if you need I/O).
In any case, I agree wholeheartedly: classes, if used properly, are an incredibly good way to streamline code. (Don't use them for everything, though. Then you get Java.) Ruby's mixins are actually very, very convenient, and seem to me to mesh well with Arc's approach: anything that can be cared and cdred can be mapped, too, and Arc doesn't care. But I feel like referring to this style as has-a is slightly weird, and it threw me off for quite a while. An object doesn't have-an Enumerable, it is-an Enumerable. On the other hand, an object does have-an #each method, so it does make some sort of sense.
Another advantage of combining mixins/has-a and Arc is that we get implicit mixins. In Ruby, you need to define #each and you need to include Enumerable to get all the Enumerable methods. But in Arc, since there are only functions, defining each would allow you to pass your object to all Enumerable functions (or their equivalent) without having to (include-mixin 'Enumerable 'MyType).
My main objection is the current state of arc.arc : Every iteration construct works with lists or strings, but it won't work well with something that has 'car and 'cdr (they check by using 'acons and 'alist, which use (is (type foo) 'cons) - meaning I had to hack into 'acons and 'alist. For that matter I had to hack into 'isa too)
Generally is-a means "object is this and only this", meaning single inheritance, which was really my meaning. But a scanner isn't a cons (it's a subset of cons; it will fail on scar and scdr). It does has-a 'car and has-a 'cdr.
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.
