Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)

[noc.near.net!inmet!spock!stt@uunet.uu.net (Tucker Taft)]

In article <1992Dec11.163811@lglsun.epfl.ch> 
  nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

> . . .
>The problem with Ada is that it is a lot more difficult to do code generation
>in my head ;-) Some of you will scoff but my education is in computer
>engineering (thus hardware) and there is a tremendous amount a satisfaction in
>knowing what it is that I am telling the hardware to do and not just in the
>abstract sense.
>
>When I program in Ada this sense of satisfaction is just not there. Programmin
g
>in C is sort of like making a piece of furniture yourself from scratch and
>programming in Ada is like buying a kit. 

I tend to agree with this assessment of Ada 83.

One of our goals for Ada 9X has been to give system programmers
back this feeling of satisfaction, so that you can do "code generation
in your head" for most Ada constructs.  In other words,
you can predict about how many machine instructions (and
generally which ones ;-) will be generated for each
construct in your program.  For a real-time embedded language,
this seems particulary important.

For example, an allocator in Ada 9X will be defined in terms
of a call on an appropriate Allocate procedure, user-replacable on
an access-type by access-type basis.
Similarly, a call on an instantiation of Unchecked_Deallocation
becomes a call on an appropriate user-replacable Deallocate routine,
preceded if appropriate by a call on a user-defined Finalize routine.

We have also provided the ability to create an access value
designating a declared variable, so long as it is marked "aliased,"
coupled with more control over by-reference vs. by-copy
parameter passing.

We also allow access to subprograms, allowing a pointer to
a procedure to be passed for the purpose of a call-back,
iteration over a data structure, etc.  This avoids some of
the heaviness and somewhat more-difficult-to-predict performance
of generics for certain simple situations.

Finally, the protected type feature is designed to allow
the construction of synchronization primitives with predictable
performance, including things like mailboxes, queues,
counting semaphores, etc.

Given some of these features, we hope that Ada 9X
will provide both the safety and high-level aspects
of Ada 83, but also the more "down-to-earth" feel appropriate for
systems programming, when you want it.

We would appreciate any specific suggestions about this 
issue of "control" or "predictability" of implementation
model, as it relates to systems programming in Ada 9X.

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138