Re: Standard Library Interest?

["Martin Dowie" <martin.dowie@btopenworld.com>]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F816F2F.1010407@noplace.com...
> I appreciate that there are plans to include stuff in the standard. Are
> you going to provide a means by which it can be extended on a regular
> basis? I can keep coming up with good ideas. I might even be willing to
> help make them real. Is there a way to get them into most
> implementations (or even my *own* implementation? By which I mean I can
> extend the library with my own personal stuff) without waiting 10 years?

I guess they will only form part of each RM every 10 years or so, but
that doesn't mean the APIWG could provide some sort of "official
status" to an API at any time in between.

The problem with API developments is (apparently) getting them
defined in RM-eze.



> Are they children of the package Ada - and hence I'm not allowed to
> modify or extend them in any way? (Or is that rule changing?) Is it
> going to be a "reference implementation" that is released regularly or
> is it "every vendor for himself?" Will it be in source code so I can
> modify it if I don't like what it does?

I think the rule has always been you can't add children to package
Ada *in normal mode* but you can add grandchildren to existing
packages, seemingly at will! At least in GNAT & ObjectAda it
is easy. I make use of this by adding non-standard but portable (for
me :-) extensions to say Ada.Calendar to add I/O.

Again, for packages that don't require compiler 'magic', it would be
nice for the APIWG to maintain a single reference implementation.

I've got a Win32 ref-imp for AI-248 @ my web site and I'm doing
a vanilla Ada one for AI-296.

But note that the status of these 2 are very different. 248 is about one
step away from being formally adopted to ISO approval but 296 is
still a "work item" - neither may yet get in!


> There's more to it than simply saying "we're adding some stuff to the
> ARM..." I still think it is the entirely *wrong* answer to cast this
> stuff into the concrete of the ARM - at least on its first pass through.
> Let the ARM pick it up in the next revision if it proves stable. But get
> a process set up to have an extensible library that can react quickly
> outside the ARM.

Again, I'd like the APIWG to do this and we should be all signing up
for this asap and being *active*.