On Thu, 9 Sep 1999, Peter Smet wrote:

> If this is the case, and tail does on occassion return a single element,
> then statements like taking the head of a list's tail just don't work.
> 
> (list tail) head  (Smalltalk syntax)

It was exactly my point to allow this - perhaps you want to try my code:

#(1 2) listTail. "2, not (2)"
#(1 2) listTail listHead. "2"
 
> For this to work you must guarantee that tail always returns a list.

I do guarantee it by defining nil to be the empty list (like Lisp does) 
*and* any other Object that is no Array to be a list with one element. 

> Otherwise you end up sending the message 'head' to a single element
> (which it won't understand).

.... if Object wouldn't understand #listHead, which it does ;-)

To clarify: My point was to only use Collections if this is necessary,
namely if you have 2 or more elements. 

I know there are some limitations like you can't have Arrays or nil as
last element of a list, but I think that's no problem here. It's not
intended as replacement for the general Collections. That's why a lispy
list isn't even a class on it's own. Actually, I added #listDo: only to
make it look more like a collection, I haven't used it in actual code yet.
(yes, #listDo: is implemented in Object, UndefinedObject and Array.
That's polymorphic fun :-)

Also worth considering might be, as you others suggested, using #head and
#tail instead of my #listHead and #listTail. The problem with these
easier-to-type selectors is that there exist some classes already using
#head and it would surely be reasonable to have some WonderlandActor
equipped with a #tail ...

One could even implement a lot of the collection protocol
(#listRemove:, listSelect: etc.) which would be extremely efficient for
empty and one-element lists.

Further comments are highly welcome!

  /bert