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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,de555fb9935cdff1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-07 13:02:11 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.gamma.ru!Gamma.RU!dispose.news.demon.net!demon!grolier!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Beard, Frank" Newsgroups: comp.lang.ada Subject: RE: Restructuring of Ada (was RE: Ada on Cypress CY7C646 (8051)?) Date: Thu, 7 Jun 2001 16:00:54 -0400 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: avanie.enst.fr 991944129 71072 137.194.161.2 (7 Jun 2001 20:02:09 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Thu, 7 Jun 2001 20:02:09 +0000 (UTC) To: "'comp.lang.ada@ada.eu.org'" Return-Path: X-Mailer: Internet Mail Service (5.5.2448.0) Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:8348 Date: 2001-06-07T16:00:54-04:00 -----Original Message----- From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com] > So it isn't that the language is > too big for most microcomputers (although you may need to be careful about > which features you use and how much you use them.) The problem comes when > you start talking about real small processors that might be able to support > an Integer-C implementation, but would have difficulty handling something > like tasking at the level required for validated Ada95. > > I don't know if you'd ever succeed in getting consensus on drawing rings > around Ada features and having something like "Tiny Ada" for small > microcontrollers, "Ada" for normal sized microcomputers and "Super Ada" that > includes all annexes. I wasn't really trying to address the size issue. I don't want to try and break it up on a "Tiny", "Normal", and "Super" size Ada. My attempt was more of a functional breakdown aimed at a reasonable process for updating the language. In some of the discussions several months ago concerning adding new features to Ada, someone replied with a concern that adding some of the new features could possible cause it to no longer be usable for embedded systems. One of my counter arguments to that was Ada.Command_Line. It is in the language but doesn't apply to embedded systems. So, we could take the approach of adding new general features and leave it to the "common sense" of the engineer to know that certain features don't apply to the embedded arena. But it seems like it would be more in keeping with the spirit of the language if we specifically defined which features applied to embedded systems and which one applied to "general" systems. Frank Beard