Re: calander package

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Well, a while ago there was an attempt to have a Standard Components working
group come up with a bunch of utility stuff like data structures, etc. For
whatever reasons it sort of collapsed. Maybe nobody had enough time to "own"
the group?

Anyway, I think the way things like date tools could make it into the Ada
language as a part of the standard would be through a process similar to
this. If there were a group of die-hard Ada fans who developed some useful
collection of general-purpose code (dates, math functions, data structures,
etc.) and it gained some level of acceptance as a pseudo-standard, then it
wouldn't be that big a deal to extend compilers to include it. (Well, O.K.
If it was part of the standard, someone would feel honor-bound to require it
be tested & that could end up looking like work!) This is certainly how a
lot of functions have made their way into C as part of the standard or a de
facto standard. Everyone just glommed onto the software and included it in
their compiler distribution within the search path.

AFAIK, it isn't required that a compiler allow you to create child packages
of standard Ada packages and this has bitten me in the past. (Not legal to
make "Ada.Numerics.My_Cool_Stuff"?) Hence it isn't likely that Calendar
itself can be extended except by the compiler writers - and you're back to
"more pressing things to do". But maybe there's some way to allow for this
kind of extension in a semi-standard way that encourages the development of
useful packages that might get adopted by the compiler vendors. For example,
if there was an "Ada.Extras" package (pick whatever name you like) that was
specified by the standard as the "standard" way of providing "non-standard"
packages as children, this might help breed non-standard extensions that
eventually become standard extensions? Hmmmm? If you use them, you know
you're not guaranteed portable - just like the optional appendices - but it
becomes the place to create utility code that might get adopted by one or
more compiler vendors?

GNAT provides some useful extensions in a similar way, but what other
compiler vendor is going to want to have GNAT.Something as part of their
product? Bad publicity. However Win32Ada seems to have been adopted as a
semi-standard, so it can be done - just not if it looks like someone else is
going to get the credit or ownership. It would be nice to see some set of
utilities migrate into Ada in some manner that gave one confidence in using
them without requiring additions to the ARM.....

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/


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:nAwr6.4569$7e6.1762378@homer.alpha.net...
>
> I've done this dozens of times, too. So, when the problem came up with
> the Smplsrvr, we went ahead and added a package of operations to Claw.
> The Claw.Time package really doesn't depend on Claw itself (nor on
> Windows), so it could be used separately. It's in the Claw Introductory
> version, which is available for free non-commerical use at
> www.rrsoftware.com.
>
> I was thinking about proposing something on this line to the ARG for
> standardization, but it unclear that the ARG is interested in
> (semi-)standardizing these sorts of packages. (It seems to run about
> 50-50 within the membership as to whether time should be spent on it.
> The objections mostly are that there are more important things to work
> on.)
>