Re: Standard Queue status

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:z9aN7.41127$xS6.69040@www.newsranger.com...
>
> 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.
>
The names can always be changed before a final release - the important thing
is that the concepts be acceptable because you can't change those once its
started. The iterator scheme is something that has to be lived with once
started. I'd favor "simple" since it is always possible to tack on a child
package that provides more fancy schemes if it seems desirable.

>
> 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 .
>
I'll take a look but the page is not coming up at the moment.


> 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.
>
I wouldn't try to make the lists be all things to all people. KISS - then
come up with fancier varieties that are variations on a theme. Extra
operations can always exist in a child package.


> 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.
>
Then keep the basic iterator you have in the Mark 1, Mod 0 package spec -
alternative iterators can be added in a child package. Keep the scope small
and simple enough that it is doable in some rational span of time and
effort. Ada is nice in allowing extensions and enhancements as we go without
upsetting the apple cart.


> 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.
>
If the subprograms can be broken into groups and the basic ones kept in the
parent, then one or more child packages that provide enhanced capabilities
is the way to go. Just because it is useful doesn't mean it needs to be in
v1.0 or the parent package. Don't discard the ideas - just stall them off
until we have something basic working and acceptable to the general public.


> 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.
>
Make an Unbounded Array a separate data type. Sure, its similar to a list,
but maybe it should be its own specialized data type because its usage will
be different and ultimately it may be better off with a different
implementation. Conversions can be handled by child packages at a later time
if it seems that they are needed.

Just my $0.02 - I think this would make a good start.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/