[J3] [Fwd: Re: [WG9] Features in Ada 202X]

Sat Oct 20 01:06:18 EDT 2018

This discussion by Randy Brukardt, a member of the Ada committees, would
be very familiar to us.  The request to which Randy responded is below
his response.

Van

-------- Forwarded Message --------
From: Randy Brukardt <randy at rrsoftware.com>
Reply-to: WG9 List <wg9 at ada-auth.org>
To: 'WG9 List' <wg9 at ada-auth.org>
Subject: Re: [WG9] Features in Ada 202X
Date: Fri, 19 Oct 2018 16:11:58 -0500

The deadline for suggestions from the public for Ada 2020 was January
15th. The deadline for suggestions from WG9 was the June meeting. This
standard is supposed to be essentially finished next April, it's way
beyond the time to even consider new suggestions. (Of course, we'll keep
them for the next version, whenever that is.) The only way to consider
these suggestions would be delay Ada 2020 for at least two years (since
it would not be fair to consider *only* your group's suggestions) [at
which point it would not be Ada 2020 anymore].

Secondly, we ask for suggestions in the form of problems that cannot be
solved effectively with existing Ada. The ARG has plenty of ability to
come up with features to solve problems. Just adding everyone's pet
features to the language is how one ends up with a hodge-podge language
(the dreaded "committee-designed language").

Some specific comments on the three requests:

(1) has been on the radar a long time. See AI12-0017-1. However,
experiences with similar features in Java and C++ has been very
negative, so there is a vocal ARG component that does not want to do
that in any form. I personally believe that it is obvious where the Java
and C++ went wrong, and Ada can avoid those mistakes, but the job is to
convince enough others to progress a proposal. That hasn't happened to
date, and AI12-0017-1 will not be in Ada 2020, but it does remain open
for the future.

(2) is a case where the problem to be solved is critical. Ada has two
existing ways to get task (there aren't threads in Ada 2012) specific
objects -- local objects in a task type declaration (obviously
preferred) and task attributes. (If one declares the task attribute to a
pointer at some other data, one can make arbitrary objects task
attributes, regardless of any restrictions imposed by the
implementation.) So we would need to see a problem that cannot
reasonably be solved by one of these options before even considering
some additional features. (As we like to always point out, every new
feature has a cost, in implementation, in education, in testing
resources, and so on; there is no such thing as a no-cost feature. So
there always has to be a cost-benefit analysis.)

(3) Ada 2020 already is making the existing container libraries more
task-safe, by adding guarantees for reading, by adding stable
containers, and by adding parallel iteration. We have further task-safe
containers on the work list, although given the progress to date it
seems unlikely that these will actually make it into Ada 2020 (I think
these would take 2-3 years of work on their own). One issue is that
"task-safe" means different things to different people; a totally
task-safe library would be very expensive. For most problems, it seems
better to add locking on top of the existing containers.

In any event, it is highly unlikely that Ada would adopt a different API
than in the existing Ada.Containers, as that would solve no problems
whatsoever, just add confusion. There is of course nothing stopping a
major project from using the tools provided by the language to create
their own containers, using whatever API that they like. Such a package
could have similar functionality and similar performance to the
language-defined containers, and could be completely portable (one of
the requirements that we have the Ada.Containers is that they can be
(but don't have to be) implemented in portable Ada code).

Again, having examples of problems that cannot be solved with the
container enhancements proposed for Ada 2020 would be valuable.

                                   Randy Brukardt, Editor, ISO/IEC 8652

P.S. These opinions are purely my own, I did not consult with any other
ARG members before writing them.

        ________________________________________________________________
        From: Alok Srivastava [mailto:asrivastava at yahoo.com] 
        Sent: Friday, October 19, 2018 6:08 AM
        To: WG9 List
        Subject: [WG9] Features in Ada 202X

        Dear WG9 Members,

        I am part of the team which develops En-route Air Traffic
        Control (ATC) systems primarily for the US Federal Aviation
        Admiration (FAA). Leidos is the prime development contractor
        with Raytheon and CSC (CSRA) as mission contractors. Earlier
        Leidos’s ATC division was part of IBM and Lockheed Martin. I
        myself through my company Engility (SAIC) work as an Advisor to
        the FAA Program Office in the development, acquisition,
        maintenance and EOL of the ATC systems.

        The recently commissioned core En-route ATC system called
        ERAM https://www.faa.gov/air_traffic/technology/eram/ has been
        primarily developed in Ada with end of life expected to be next
        35-40 years. The software size of ERAM now has exceeded more
        than two million of lines of code.

        Therefore, FAA has a considerable interest in the Ada SW
        Engineering and its future. I regularly share the developments
        in the Ada Technology with my team. At present most of the new
        development is occurring using AdaCore’s GNAT Pro Enterprise,
        not only for the Ada but also for the C and C++ code. I stated
        in the last WG9 meeting in the Lisbon that I will also be
        seeking suggestions and expectations with my team on next
        compiler’s specs.

        Below is a message from Lead “Flight Services” component
        development team.

        I will appreciate if you look into that, provide your advice and
        consider as part of the enhancements for Ada 2020. If needed you
        can also call Howard Ausden on Monday at 301 943 4689 (Cell) or
        301 240 6358 (Office) for any clarifications. In the past Howard
        has served HILT conferences as Program Committee member. Richard
        Schmidt in the message was keynote speaker at SIGAda 2009

        http://www.sigada.org/conf/sigada2009/

        Thank you in advance,

        Alok

        ==============

        Alok Srivastava, Ph.D.

        Engility Technical Fellow

        Expert Panelist, National Science Foundation (NSF), Comm. &
        Cyber Systems Div.

        Space and Missions Systems

        Phone:  202.314.1419 | Cell:  571.276.4066

        Alok.Srivastava at Engility.Com

        cid:image001.png at 01D4298F.405213D0

        80 M Street, SE, Washington, DC 20003

        engility.com

        =================

        From: Ausden, Howard C. [mailto:Howard.C.Ausden at leidos.com] 
        Sent: Wednesday, October 17, 2018 3:12 PM
        To: Srivastava, Alok @ Engility <Alok.Srivastava at Engility.com>;
        Schmidt, Richard B. <Richard.B.Schmidt at leidos.com>
        Cc: Jeff.oleary at faa.gov;

        Subject: RE: Features in Ada 202X to support ERAM EOL

        Hi Alok,

        Thanks for the invitation to submit suggestions!  We asked the
        development team and came up with the following 3 suggestions.
        Let us know if the language team needs more information or wants
        to discuss.

        1.       A way in Ada to declare what exceptions a given
        subroutine can throw in the API spec, so the compiler can check
        that callers handle possible thrown exceptions and provide a
        warning or error if not handled by the caller (or the caller
        could explicitly state intent to propagate).  This can be done
        in Java.  Ideally the compiler would also warn if the specified
        list of possible thrown exceptions is incomplete, e.g. some
        lower-level routine may raise an exception which isn’t in the
        list in the API spec.

        2.       Thread specific variables.  GNAT supports them with GCC
        extensions but we would like them to be available with other
        compilers.

        3.       A threadsafe container library, ideally with a similar
        API to the Booch components.  Porting code to run on multiple
        cores is a challenge when fundamental components are not
        threadsafe even for multiple reader tasks (read access to many
        of the Booch components modifies caches and reference counts and
        thus tasks interfere with each other).

        Thanks

        -Howard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20181019/8a416265/attachment-0001.html>