Re: Container reqs

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

We're probably not far off in terms of goals and objectives. I'd just like
to actually see something emerge from this process that has a concrete
result and a significant benefit to Ada. My fear is that with an informal
sort of process like this, it will drift in too many directions for too long
until eventually interest wanes and we don't see anything come of it. Its a
problem for volunteer projects. If there were a dozen of us getting paid to
do it and we had a deadline, I have every confidence that we'd hammer out
something. As it is (and without some indication of support/endorsement from
vendors) its hard to see a concrete result emerging any time soon.

By "Lists" I have in mind a dynamically allocated, doubly linked list. In my
experience, things like stacks and queues (at least dynamic ones) are just a
subset of calls to a doubly-linked list and so they don't get used much in
practice. (We could debate for hours the relative merits and usefulness of
static/dynamic stacks/queues/lists/double-lists/etc. All that is "nice" and
"interesting" but I think that just getting a doubly-linked-list package
available would probably handle enough practical conditions that it would
get beat to death in normal usage.)

I would note that the MFC basically provides some version of Lists and Maps
and no other particular data structures. (Depending on what arguments one
wants to have about what constitutes a "Data Structure". I'm thinking about
just a general container kind of thing.) Hence getting just that far would
bring us up to par with MSVC++ in that area. Not that I want to duplicate
everything in the MFC, but lots of people write lots of code using it and
they get lots of mileage out of Lists and Maps available to them there. It
isn't *everything* but it is, as I have observed, A Good Start.

Now I can see the point about wanting to get the right concepts together so
that extensions don't start becoming a problem. Should these be generic or
some form of OO Inheritance? (I'm thinking generic for a "basic" set) Should
they have private, limited and/or tagged parameters? (I'd start with "Basic"
as the rule and create variants - make a set with private parameters and
clone them off for limited/tagged usage.)

I'm still hoping to see some support for a basic set of data structures.
Take a look at the standard/semi-standard libraries that come with other
languages or products and you can see signs that they did not start out in
life with "The Grand, Unified, Theory Of Code Libraries" guiding their every
development. Most of them look like they started out small and had branches
and wings added on to them over time. So long as the initial development
doesn't hopelessly hamstring future add-ons, and the initial cut at it
provides some useful, core tools, I'd think we had something O.K. to adopt
and build on.

Heck! I'd get on board with one of the existing packages if there was some
emerging consensus from the users and some buy-in from the compiler writers.
So far, there seems to be neither, so I think it would be better to come up
with some small core of things that *could* be agreed upon as being
generally useful and *might* get some buy-in from the compiler vendors. I
don't know if I'm a lone voice crying out in the wilderness over this or
not. I'd suspect that most Ada users would be happy to see their compiler
come with a library full of stuff they could use with some confidence that
it would be portable to other compilers and didn't require a masters degree
in CS to figure out how to use. I hope we can get that far.

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/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9r9rqj$5dh$1@news.huji.ac.il...
> I agree with almost all your points.
>
> Indeed we can start with some minimal number of conponents, and build on
> from there. I also agree that endless debates, are - well - endless...
>
> My only concern is that without some overall design, you'll end up with a
> pile of packages, and not one consistent library.
> I want things to compose nicely, and be extendable.
>
> That's also why I agree that debating the various existing libraries,
though
> educational is not "good for the cause".
>
> Still, I'd feel better with something organised by ADT properties. Thus
MAPS
> are fine, where as I'd like clarification about Lists. Are we talking
> sequential structures, or about the implementation as linked sturctures?
>
> I prefer maps, queues, dequeues etc.
>
> Ehud
>
>