RE: Restructuring of Ada (was RE: Ada on Cypress CY7C646 (8051)?)

["Beard, Frank" <beardf@spawar.navy.mil>]

-----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