From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-ada
From: larry@JPL-VLSI.ARPA
Newsgroups: net.lang.ada
Subject: SYSTEM and other Ada extensions
Message-ID: <8511280207.AA10229@ucbvax.berkeley.edu>
Date: Wed, 27-Nov-85 20:48:40 EST
Article-I.D.: ucbvax.8511280207.AA10229
Posted: Wed Nov 27 20:48:40 1985
Date-Received: Fri, 29-Nov-85 00:14:32 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

The SYSTEM package is part of a larger problem.  Despite AJPO's "There 
shall be no supersets" policy, the fact is that the LRM itself explicitly 
allows supersets in several ways.  Representation specs are optional, 
pragmas and attributes beyond the "kernel" set are allowed, etc.

I believe this is desirable; Ada will be no use unless it can be expanded 
and tailored to suit specific applications and environments.  The problems 
this causes are obvious, but lessened by various mechanisms to control 
supersets (or whatever word you choose to avoid "superset").  They include: 
extensions beyond the kernel must be described in Appendix F; the package 
feature lets us insulate application/ environment specifics from the rest 
of a system; the real-time working group is channeling effort to expand 
Ada's real-time capability; and a new LRM is planned for every five years.

But more work does need to be done to control Ada expansion.  I'm less 
concerned about vendor efforts (which tends to be conservative) than I am 
about utility libraries which can be created by any programmer.  I'm not 
sure what the answer here is.
                                        Larry @ jpl-vlsi