Re: List container strawman 1.2

[Ted Dennison<dennison@telepath.com>]

In article <3BF052D3.ECEF3FF2@san.rr.com>, Darren New says...
>
>Ted Dennison wrote:
>> there is better. "Font" and "Back" are pretty standard terminology for list

Hmmm. Reading this over, "Head" and "Tail" are actually more usual, aren't they?

>OK, well, is the front of the list the first element? If so, why do they

That's actually a very good question. It isn't an array, so you can't tell from
that. The way the list is designed, I can use it as a queue or as a stack from
either end and it will work just fine either way. 

The iterator, on the other hand, has a different job to perform. In its world,
all it has to do is pick a side, and then go the other way until the end. So
there it makes more sense to talk about "First" and "Last". 

However, you have to pick a side, and it would be useful to know how to relate
the two. So you are right that this *is* a bit confusing, because somewhere you
have to realise that "First"="Head". But renaming "Head" to "First" won't remove
the confusion, because that term has no real meaning in the universe of Push'es
and Pop's.

So how do we get out of this. The best ways that I can see are either:

o  Make sure the iterator routines are well commented as to which 
directions in the "Head/Tail" world they operate.
o  Rename the iterator routines to match the other routines. 
Unfortunately, this would reqire "Next" and "Previous" to become
something like "Next_Toward_Tail" and "Next_Toward_Head". The
passive iterator would still have to be commented as to which 
direction it goes. I suppose a From_Head/From_Tail flag could be 
used instead. That might be useful anyway...

I think the second option is quite doable, if that's what people really want.

>It's not uncommon, usually when the sub-lists being inserted "mean"
>different things, like you're inserting the children of the directory
>after the directory entry during a breadth-first walk, say. And "&" has

So what you are saying is that there is a hetrogenious structure to your list
that isn't reflected in the structure of the list itself, but in the contents of
the elements in the list (and thus has to be parsed back out)? You could
accomplish this goal without the extra parsing (and without the middle insertion
routine) by using lists of lists, could you not? 

You are right about the level-of-effort vs. the append routines, though.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.