Re: Ada is almost useless in embedded systems

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <RALW.96Mar13101857@vulcan.gecm.com> bill.williams@gecm.com writes:

  > When you're inspecting someone elses code I like the shortcuts that the
  > rich C operators give you. My favourite example has got to be the
  > assignment operators, += etc. Take this (contrived) case...

  > How much easier to *require* (by means of coding standards etc.) the
  > first to be written

  >   bibble_bobble.wibble_wobble += 3;...

  > And what if the coder had actually meant

  > OK, these names are clearly fatuous. But similar cases *do* arise in
  > complex software where, for perfectly sensible reasons a coding standard
  > requires all variables and structure members to have 'meaningful' names.
  > I don't think Ada is immune to this sort of problem.

   No, but the differnce is cultural, not linguistic.  There have been
programs where I needed to do lots of incrementing and declared:

   procedure Inc(X: in out Integer; Y: in Integer := 1) 
   is begin X := X + Y; end Inc;
   pragma Inline(Inc);

   ...and then went and used it all over.  I even had one program that
provided half a dozen similar operations, and instantiated it for
several integer types.  Note that I COULD have written things in terms
of the 'SUCC attribute, but the Ada cultural convention seems to be to
only use 'SUCC and 'PRED for enumeration types, or generic formal
enumeration types.
  
  > > (6) Strong Typing: In the Ada code, the type casting is and must
  > >     be explicity coded.  This provides secure compile-time
  > >     documentation of how big each integer is at each step. This
  > >     is especially useful when you are doing something tricky,
  > >     like writing over memory in a segment register.

  > I approve of strong type *checking*. As we all know (except those
  > who either never write any 'difficult' apps. or never test what
  > they write) type mismatches are a major cause of errors. What
  > irritates me about Ada (and Eiffel is even worse!) is that when *I
  > know* that what I am doing is desirable and correct the language
  > won't let me produce a concise and easily readable expression of
  > it. And, no, I don't consider having to declare my conversion
  > routines in one part of a program so I can use them elsewhere a
  > particularly neat way of solving the problem. Ada deliberately
  > makes it 'unpleasant' to do an unchecked_conversion. IMO it goes a
  > bit too far.

    Ah, but in Ada CHECKED conversions are easy to write and don't
require declarations.  

    In Ada "X := Float(Y);" does just what you would expect, convert Y
to Float and assign it to X.  It is defined for Y of any numeric type.
In fact, when you declare any numeric type you also implicitly create
such a conversion operation.  You also get well defined conversion
operations with derived type declarations, and with many array
declarations.  It is only where you need to convert between types with
no obvious mapping, or when you specifically want no checking, that
you have to resort to Unchecked_Conversion.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...