ARG asks Ada Community for API Proposals.

ARG asks Ada Community for API Proposals.

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

The Ada Rapporteur Group (ARG) is the technical committee in charge of
proposing amendments to the language to WG9, the ISO working group on
Ada. The ARG has begun work on the next revision of Ada, planned for
2005. As part of this revision, there has been a lot of interest in the
Ada community for the standardization of reusable components and APIs to
existing services.

While the ARG will conduct (based on input from the Ada community) the
revision of the core language and annexes, it doesn�t have the resources
to develop proposals itself for the standardization of reusable
components or APIs. Standardization of components or APIs often will
best be accomplished with secondary standards rather than part of the
core language standard. The ARG will oversee the development of such
secondary standards, but this is best accomplished by cooperating with
external groups developing the substance of such standards.

Therefore, the ARG would like to ask the Ada community to submit
proposals for
the standardization of APIs. Proposals must include (at least) a set of
Ada specifications, and a semi-formal description of the semantics of
each declaration, such as can be found in the annexes of the Reference
Manual. Developing such proposals usually will require the formation of
formal or informal working groups.

The ARG will evaluate these proposals using a variety of criteria. For a
more detailed version of this announcement, including a (partial) list
of evaluation criteria, please see
http://www.adaic.org/news/call4apis.html.

         Randall Brukardt
         Editor, ISO/IEC JTC1 SC22 WG9 ARG

Re: ARG asks Ada Community for API Proposals.

[Ted Dennison]

Randy Brukardt wrote:

> Ada. The ARG has begun work on the next revision of Ada, planned for
> 2005. As part of this revision, there has been a lot of interest in the
> Ada community for the standardization of reusable components and APIs to
> existing services.

...

> The ARG will evaluate these proposals using a variety of criteria. For a
> more detailed version of this announcement, including a (partial) list
> of evaluation criteria, please see
> http://www.adaic.org/news/call4apis.html.


I notice from the website that the critera seem to be stilted towards 
existing libraries like Booch. Anything from the Grace project would 
have trouble competing due to two factors:

    1) Its new. The critera prefer stuff that's been used for a while.

    2) Functionality. Grace has as a goal to try to balance power-user 
functionality with beginner (eg: CS1 and 2) ease-of-use. The critera 
appear to select only for functionality.


Not that I have a big problem with this. I've said all along I'd prefer 
to see Booch in the standard. :-)

Re: ARG asks Ada Community for API Proposals.

[Randy Brukardt]

Ted Dennison wrote in message <3CEDA711.5040303@telepath.com>...
>I notice from the website that the critera seem to be stilted towards
>existing libraries like Booch. Anything from the Grace project would
>have trouble competing due to two factors:
>
>    1) Its new. The critera prefer stuff that's been used for a while.
>
>    2) Functionality. Grace has as a goal to try to balance power-user
>functionality with beginner (eg: CS1 and 2) ease-of-use. The critera
>appear to select only for functionality.
>
>
>Not that I have a big problem with this. I've said all along I'd prefer
>to see Booch in the standard. :-)


Speaking for myself (not necessarily the ARG), I don't think you should
read too much into those criteria. They certainly were not intended to
be an exclusive list. To my mind, the important point is that the
libraries have a community consensus (where "community" is intentionally
vague), and are not just something written by someone in their basement.
If Grace has a consensus, then it will necessarily meet the usage
criteria, if not immedately, certainly by the time the standard gets
done.

As far as point 2 goes, it seems to me that the ease-of-use criteria got
omitted. I don't think anyone wants complex solutions where simple ones
will do. Going overboard on functionality can be a mistake, because if
the package is too large, people will have trouble using it.

Besides, I doubt that many groups are going to be willing to undertake
the commitment that it will take to see this through from start to
finish. Personally, I'd be happy if anybody steps up here...

               Randy Brukardt.

Re: ARG asks Ada Community for API Proposals.

[Dale Stanbrough]

In article <uet84otoe3m4c4@corp.supernews.com>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> Speaking for myself (not necessarily the ARG), I don't think you should
> read too much into those criteria. They certainly were not intended to
> be an exclusive list. To my mind, the important point is that the
> libraries have a community consensus (where "community" is intentionally
> vague), and are not just something written by someone in their basement.
> If Grace has a consensus, then it will necessarily meet the usage
> criteria, if not immedately, certainly by the time the standard gets
> done.
> 
> As far as point 2 goes, it seems to me that the ease-of-use criteria got
> omitted. I don't think anyone wants complex solutions where simple ones
> will do. Going overboard on functionality can be a mistake, because if
> the package is too large, people will have trouble using it.


What are the likely new features of Ada though? If we have 
can have some form of implicit instantiation of generics, or
if Ada provides fully fledged constructors (not just functions)
or if Ada deprecates the use of some features, then all of these
could well affect the design of any class libraries.

Perhaps Ada needs to have a library standardisation process
which is 180 degrees out of phase with the language standardisation,
so that we can incorporate features placed into the language.

Dale

Re: ARG asks Ada Community for API Proposals.

[Ted Dennison]

Dale Stanbrough wrote:

> What are the likely new features of Ada though? If we have 
> can have some form of implicit instantiation of generics, or
> if Ada provides fully fledged constructors (not just functions)
> or if Ada deprecates the use of some features, then all of these
> could well affect the design of any class libraries.


A damn good point. We have already discovered during the process of 
defining the Grace container packages that lack of default values for 
generic instantiations causes us to have to throw out a lot of features, 
lest we run afoul of our instantiation simplicity requirements.

It would be a damn shame to end up with something like that in the 
standard, along with the new features that make the trade-offs unnessecary.

However, I do think a lot of stuff that we didn't put in due to lack of 
default generic parameter could be added at a later date without huge 
structural changes. Presumably there will be a webpage somewhere where 
folks can go to keep themselves abrest of the latest proposed language 
changes.

Re: ARG asks Ada Community for API Proposals.

[Dale Stanbrough]

Ted Dennison wrote:

> A damn good point. We have already discovered during the process of 
> defining the Grace container packages that lack of default values for 
> generic instantiations causes us to have to throw out a lot of features, 
> lest we run afoul of our instantiation simplicity requirements.
> 
> It would be a damn shame to end up with something like that in the 
> standard, along with the new features that make the trade-offs unnessecary.
> 
> However, I do think a lot of stuff that we didn't put in due to lack of 
> default generic parameter could be added at a later date without huge 
> structural changes. Presumably there will be a webpage somewhere where 
> folks can go to keep themselves abrest of the latest proposed language 
> changes.

Perhaps we should have a package structure that includes versioning
information...

   e.g.

      package Ada95 is end;
      package Ada95.Containers is...

      package Ada05 is end;
      package Ada05.Containers is...

to allow for different language features. This would allow for
upgrades in the future while not requiring existing code to be 
modified.

Do we have access to the list of features that have been proposed
for Ada0Y?

Dale

Re: ARG asks Ada Community for API Proposals.

[Simon Wright]

"Robert C. Leif" <rleif@rleif.com> writes:

> As for the API, it should be based on XML. If we can not have one
> programming language, we should limit the number to two.

OK so far

>                                                          Ada and XML are
> similar

huh?

>         and complement each other.

back to reality :-)

RE: ARG asks Ada Community for API Proposals.

[Robert C. Leif]

From: Bob Leif
To: Dale Stanbrough et al.
The libraries should be kept separate from the standard. The period
between revisions to the Ada standard is way too long for bindings to
other software, such as XML. Many libraries should be first created by
some sort of consensus system and tried out as provisional standards.
Then, they can be promoted to being an annex or a part thereof. Many of
the annexes should be decoupled from synchrony with the standard.
Besides permitting the necessary adaptability at the periphery of the
Ada standard, it will permit a continuous rather than a batch approach
to the maintenance of the language. In short, we should follow the old
software principle of divide and conquer.

As for the API, it should be based on XML. If we can not have one
programming language, we should limit the number to two. Ada and XML are
similar and complement each other.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Dale Stanbrough
Sent: Friday, May 24, 2002 2:48 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: ARG asks Ada Community for API Proposals.

In article <uet84otoe3m4c4@corp.supernews.com>,
 "Randy Brukardt" <randy@rrsoftware.com> wrote:

> Speaking for myself (not necessarily the ARG), I don't think you
should
> read too much into those criteria. They certainly were not intended to
> be an exclusive list. To my mind, the important point is that the
> libraries have a community consensus (where "community" is
intentionally
> vague), and are not just something written by someone in their
basement.
> If Grace has a consensus, then it will necessarily meet the usage
> criteria, if not immedately, certainly by the time the standard gets
> done.
> 
> As far as point 2 goes, it seems to me that the ease-of-use criteria
got
> omitted. I don't think anyone wants complex solutions where simple
ones
> will do. Going overboard on functionality can be a mistake, because if
> the package is too large, people will have trouble using it.


What are the likely new features of Ada though? If we have 
can have some form of implicit instantiation of generics, or
if Ada provides fully fledged constructors (not just functions)
or if Ada deprecates the use of some features, then all of these
could well affect the design of any class libraries.

Perhaps Ada needs to have a library standardisation process
which is 180 degrees out of phase with the language standardisation,
so that we can incorporate features placed into the language.

Dale

RE: ARG asks Ada Community for API Proposals.

[Robert C. Leif]

From: Bob Leif
To: Simon Wright
" Ada and XML are similar huh?" 
I have sent in an article about this to Ada Letters. Very briefly, Ada
and XML both have enumerated types, begins and ends, and range checking.
XLM schemas are very similar to the Ada specifications without the
subprogram declarations. XML schemas import other schemas and
effectively rename with a prefix construct. 

The commercial success of XLM disproved most of the marketing arguments
against Ada. Ada is terse compared to XLM. The XLM languages have a
plethora of key words. XLM does not have C like syntax. However, XLM has
real marketing, which Ada never had.



-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Simon Wright
Sent: Saturday, May 25, 2002 1:03 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: ARG asks Ada Community for API Proposals.

"Robert C. Leif" <rleif@rleif.com> writes:

> As for the API, it should be based on XML. If we can not have one
> programming language, we should limit the number to two.

OK so far

>                                                          Ada and XML
are
> similar

huh?

>         and complement each other.

back to reality :-)

Re: ARG asks Ada Community for API Proposals.

[Marin David Condic]

Are you suggesting that the ARG in some way maintain an effort to define
what constitutes the "Standard Ada Libraries" - beyond what appears in the
annexes? I'd think that would be a fine idea provided that a) they were
willing to take on that responsibility and b) came up with a process that
allowed for rapid turnaround on getting new features in. If the ARG can't
take on that work or can't update faster than a ten year revision cycle,
then they'd be the wrong organization to do the job. At one time there was a
branch of SIGAda that was willing to try, but couldn't come up with a
standard component collection. If the ARG doesn't want to handle it, maybe
SIGAda should take another crack at it.

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


"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-493D0A.18474725052002@mec2.bigpond.net.au...
>
> Perhaps Ada needs to have a library standardisation process
> which is 180 degrees out of phase with the language standardisation,
> so that we can incorporate features placed into the language.
>

Re: ARG asks Ada Community for API Proposals.

[Marin David Condic]

But the easy answer to that is to have a separate library "standardization"
process that can turn around changes quickly and maintain multiple versions
or levels of standard. The example of default generic parameters is a good
one. At present it doesn't exist so "Containers Standard Level 1" provides
an interface wherein you have to supply more parameters or live with
limitations. If the language comes up with a revision that makes other
things possible, then you come out with a "Containers Standard Level 2" that
exploits it. A vendor can say "I'm Level 1 Compliant" and need never move
from there. They can add Level 2 any time they like. As long as the
libraries can be revised quickly to incorporate new technology or to extend
into new areas, we wouldn't have to worry about much slower language
revisions. Stability is nice, but 100% stability is "stagnation" and
libraries are *far* easier to update than are compilers.

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


"Ted Dennison" <dennison@telepath.com> wrote in message
news:3CEED532.2090701@telepath.com...
>
> It would be a damn shame to end up with something like that in the
> standard, along with the new features that make the trade-offs
unnessecary.
>

Re: ARG asks Ada Community for API Proposals.

[Marin David Condic]

Not a bad idea, but a granularity of 10 years is not going to make Ada very
reactive to changing needs. I'd imagine an update cycle of 1 year being
about as long as it ought to go. Also, you'd want to consider that some
sections of the library might be highly stable while other sections might go
through more revisions/extensions. Would it be better to maintain them all
as separate things rather than house them all under an "Ada03" or "Ada04"
root? It might be more conducive to maintaining multiple versions/levels of
libraries with substantially different capabilities.

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


"Dale Stanbrough" <dstanbro@bigpond.net.au> wrote in message
news:dstanbro-AB7971.22342925052002@mec2.bigpond.net.au...
>
> Perhaps we should have a package structure that includes versioning
> information...
>
>    e.g.
>
>       package Ada95 is end;
>       package Ada95.Containers is...
>
>       package Ada05 is end;
>       package Ada05.Containers is...
>
> to allow for different language features. This would allow for
> upgrades in the future while not requiring existing code to be
> modified.
>
> Do we have access to the list of features that have been proposed
> for Ada0Y?
>
> Dale

Re: ARG asks Ada Community for API Proposals.

[Dale Stanbrough]

Marin David Condic wrote:

> Not a bad idea, but a granularity of 10 years is not going to make Ada very
> reactive to changing needs. I'd imagine an update cycle of 1 year being
> about as long as it ought to go. Also, you'd want to consider that some
> sections of the library might be highly stable while other sections might go
> through more revisions/extensions. Would it be better to maintain them all
> as separate things rather than house them all under an "Ada03" or "Ada04"
> root? It might be more conducive to maintaining multiple versions/levels of
> libraries with substantially different capabilities.

The idea was to base the naming convention based on the version of the
language required to run the software. For example you could not use the 
requeue facility under Ada83, so it would have to be placed under an 
Ada95 package hierachy (whereas software that didn't could be placed 
under an Ada83 package hierachy :-).

This is not denying the need to be able to produce many revisions of
the same software.

For example you may have

   Ada95.Containers.Protected_Lists

which could require the requeue feature of Ada95 going through
multiple revisions. the Ada95 name only says "you need to compile
this with an Ada95 compiler".

If Ada05 introduces the reserved word "discombobulate", then clearly
none of the packages under Ada95 hierachy could use it.

The benefit of this is that replacement packages  could be created
relying on new language features, and all it would take for a client
to use the new library would be to change "Ada95" to "Ada05".

Dale

Re: ARG asks Ada Community for API Proposals.

[Randy Brukardt]

Marin David Condic wrote in message ...
>Are you suggesting that the ARG in some way maintain an effort to
define
>what constitutes the "Standard Ada Libraries" - beyond what appears in
the
>annexes? I'd think that would be a fine idea provided that a) they were
>willing to take on that responsibility and b) came up with a process
that
>allowed for rapid turnaround on getting new features in. If the ARG
can't
>take on that work or can't update faster than a ten year revision
cycle,
>then they'd be the wrong organization to do the job. At one time there
was a
>branch of SIGAda that was willing to try, but couldn't come up with a
>standard component collection. If the ARG doesn't want to handle it,
maybe
>SIGAda should take another crack at it.

The whole idea here is to create some secondary standards (like the math
libraries were handled for Ada 83) that are not necessarily part of the
Ada Language Standard. That means that they are standardized and updated
on their own cycle, not necessarily with the core language.

The ARG is involved mainly because it has been tasked with deciding the
overall direction of Ada standardization, and particularly deciding what
goes into the Ada Reference Manual and what becomes a secondary
standard. Thus, it has to get proposals at an early stage in order to
make this decision.

           Randy Brukardt
           ARG Editor (back from vacation)