Re: List container strawman 1.2

[Ted Dennison<dennison@telepath.com>]

In article <3BF0247D.4500975E@san.rr.com>, Darren New says...
>
>This is a multi-part message in MIME format.
>--------------AC397429692108B025B90E25
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit

I can't always read all parts of a MIME message w/ my regular newsreader. In
this case, your spec came through as garbage.


>>     No_Item : exception;
>>     function  Pop_Front  (Source : List) return List;
>>     function  Pop_Back   (Source : List) return List;
>
>I think calling it "Front" and "Back" here and "First" and "Last" later
>is going to be confusing.

Perhaps. But then First and Last make perfect sense in terms of iterating, and
make it clearer which way "Next" and "Previous" go, so I think the terminology
there is better. "Font" and "Back" are pretty standard terminology for list
ends, so from that standpoint they should stay too. What would you prefer to see
here?


>> >Inserting one list into another seems like overkill. If we're going to
>> 
>> It seemed that way to me too when suggested, but no one else said anything of
>> the sort, and its easy enough to code up. I'm still unconvinced that this is
>> something that folks would have to do a lot.
>
>I do it all the time in list-oriented languages. When you have a bunch
>of lists you want to merge into one, it's very handy. It makes no sense
>to leave it out, really, since it's not something you can easily code up
>yourself.

If all you want is to tack them together, the "&" functions do that just fine.
Do you actually need to merge lists by sticking one into a specific place in the
middle of the other all the time?

"next" should move the current value of a pointer, rather than returning
>the next pointer after this one, or you'll have a hard time keeping
>track of what "positions" might be valid.

No, its actually *no* tougher to keep track of valid positions either way. Even
with a limited position you have to worry about the possibility that one
position may go invalid due to operation on another position. (Or alternatively,
you don't worry about it in either case, which is what the current strawman
does). The data structures and methods for keeping track of this are the same as
they would be for non-limited positions. Making them procedures and/or limited
really buys you nothing, and prevents some very useful constructions for those
of us who like to do all the work we can in our declaration sections.

---
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.