Standard Queue status

[Ted Dennison<dennison@telepath.com>]

In article <9u0ujd$rhg$1@nh.pace.co.uk>, Marin David Condic says...
>I think that Ted proposed a package that would make a good start. But that
>rather quickly shot off in a few dozen directions with objections on all
>sorts of fronts - and it was only one little lonely list package.  I could
>still imagine taking it pretty much "as is" and adding to it a map package
>that looked similar and declaring that "Version 1.0". Any chance that
>proposal would gain any support? Anybody else have a proposed answer?
>
>I think if we don't commit to some direction pretty soon, the stagnation and
>deadlock will result in a lack of interest and this will wither on the vine.
>Too bad. Its a good idea and a noble goal.

I think I'd best say that I should shoulder a fair bit of the blame for that.
First off, I *asked* for more discussion when some were apparently ready to move
toward implementing what we had. I'd hoped a bit more polishing (particularly
anound the subprogram names and the implementation of the iterator) would
achieve us a broader consensus. 

My second crime was that I went and purchased Civ3, which has proceeded to suck
up all my computer time for the last couple of weeks, along with a good chunk of
my sleep time as well. :-(

To get things back on track, I'd like to ask if there is anything in Nick's
proposal that there is general consensus on putting in the strawman (or we could
take it the other way, if that's what folks want). If you want to look at it,
the package in question is at
http://www.adaos.ukf.net/njr05/scl-lists-unbounded.ads.html .

Personally, I like his use of the "Direction" type to specify which end to start
from in his operations. I also like the ability to convert between lists and
unbounded arrays. I think those may merit putting in the final version. There
are also a number of operations in there that the strawman doesn't have which
some folks may find useful.

On the other hand, I'm not a big fan of the iterator approach used. In an
"unbounded" package, I don't think the user should have to worry about running
out of resources like iterators. That sort of breaks the whole "unbounded"
philosophy. 

Also I think there are too many operations in there. The package spec is huge.
It has (by my count) 79 subprograms. The current strawman has 34, which to some
people it seems is annoyingly small, as we keep seeing suggestions for
additions. Perhaps in between there somewhere the truth lies. 

A large culprit here seems to be the unbounded-array support, which is probably
taken a bit too far. Its OK to convert between them, but anything much more
should probably be accomplished by first converting the array to a list. If we
take Ada.Strings.Unbounded as a model, only the infix operators should have
unbounded array equivalents.

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