Re: Grace and Maps (was Re: Development process in the Ada community)

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

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0204190529.559a47ae@posting.google.com...
>
> I've actually been thinking along similar lines. What I'm wondering is
> if we should keep the list package as "Lists.Unbounded", or if we
> should just bag the whole bounded/unbounded issue and make it "Lists".
>
>
O.K. Let's cash in our reality checks and see if they bounce. Would it be
fair to say that *most* Ada developers and applications are some flavor of
Windows/Unix with no realtime requirement beyond "Don't run so slow as to
annoy the user..."? If that's the case, then we're looking at virtual memory
machines that probably run very fast and hence, having fixed or bounded
lists doesn't seem like it would be very important.

If we put out a Grace.Lists and a Grace.Maps, that would certainly be a
really good start. If at a later point in time there was some kind of
groundswell indicating that there really was a need for bounded versions,
why couldn't we go with Grace.Lists.Bounded as an extension? The only reason
I can think of is that it isn't consistent with Ada.Strings.

An interesting observation: When I write most apps for a PC in Ada, I tend
to use the standard, fixed strings only at the points where Ada defined
functions require them. (Stuff like Text_IO) The rest of the time, I just go
to Unbounded because from a programming perspective, its just so much more
convenient. In most instances, whatever performance penalties might exist
for it are so far below the noise floor that they are invisible. Is this
experience unique to me or would most Ada programmers report similar
experience? If Ada were to totally abandon fixed and bounded strings (in the
sense that they were never there - not from any sort of compatibility
perspective), would you notice or care most of the time? (Presuming you
could get them via some add-on package of your own creation if you ever
really needed them?)

My inclination would be to make Grace.Lists and Grace.Maps and add children
at a later date if we thought we needed special cases. I'd again make an
appeal for some version of "Grace.Containers.Lists" and
"Grace.Containers.Maps" (or some variant thereof) so that there might also
be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML",
"Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real
important to me but thinking along the line of problem domains & dividing
things up under a subheading is something I think would be beneficial in the
long run.



> >
> > If the Lists specification is considered done, perhaps its time to look
at
> > it with an eye towards proposing a Map specification?
>
> Indeed. I still don't have the website up unfortunately (I've never
> used ssl before, which is required to upload things, so I'm having
> "issues".) But the last published proposal spec is still available at
> http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html
> to refresh everyone's memory.
>
I've still got the link bookmarked and could possibly spend some time
developing some test code, etc., if you think that's of value. (Do you have
a body in some preliminary state I could work to?)

I don't think you need to have the full-blown project setup done in order to
discuss an interface to Maps. What would you suggest as a means of getting
that ball rolling? Would you like someone to take the Lists spec and turn it
into a strawman for Maps? (I hear you're a little preoccupied at the
moment... :-)

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