Re: ForTran-Ada + flamette + question

[BBardin@USC-ISIF.ARPA (Bryce Bardin)]

The discussion of whether Ada should support procedures as variables and
parameters seems to be a miscommunication, at least in part.  Some people
say that Ada can't support the concept well enough to be useful and that
they can't live without the feature.  Others argue that Ada doesn't need
the feature.  Still others point to the Steelman requirements that ruled
it out.  I would like to address the following points:
	(1) Does Ada support procedures as variables, and
	(2) Does it support it well enough?

Firstly, Ada has a consistent model of static (compile/link-time)
checkable semantics based on the concept of strong typing.  This is 
supplemented by run-time checking to assure that values do not go outside
their defined ranges.  (High-quality implementations are able to remove most
of these checks by analyzing the code carefully.)

The purpose of these concepts is to assure that with reasonable care, robust
programs can be written.  Ada deliberately seeks to minimize the risks of 
writing incorrect code, although it cannot provide absolute protection, of 
course, and it does not prevent incorrect usage of the facilities it provides.

Within the Ada model there are two options, both of which allow Ada to 
provide safety:  using a case statement on an enumeration type and 
instantiating a generic unit which has a generic formal subprogram 
parameter.  Both of these mechanisms are simple and straightforward to use
in the case of static binding, and both can be implemented efficiently.

(Those of you who object on aesthetic grounds to these techniques simply do
not yet appreciate the value of strong typing.  You can only be
convinced by being condemned to manage the implementation of a 250,000
line system in FORTRAN, Pascal, or (better yet) in C and then being allowed
to re-implement it in Ada, for comparison.)

Secondly, Ada has mechanisms for escape from the strict strong-typing
semantics.  In particular, there are Unchecked_Conversion, address clauses,
and pragma Interface.  Implementations exist with all of these features 
(and you who wish to live dangerously, i.e., to indulge in weakly-typed
programming, should insist that your favorite Ada compiler support them
properly).  With a simple C or assembly language routine or two, you too
can execute data in Ada!  All kidding aside, it is clear that for those
who want to do run-time binding of procedures, this is a legitimate approach
which should meet your immediate needs.  Roughly, all you have to do is to
load the code to be executed into a data object, figure out where its entry
is, add the appropriate offset to the address of the data object (performing
appropriate (unchecked) conversions along the way, and pass the resulting
value to the (non-Ada) module which you have imported into the Ada program
using pragma Interface for it to execute.  Of course, there are a couple of
drawbacks:  you can hang yourself and it ain't portable!  (So what's new!)

With regard to the second question, it is mainly a philosophical issue.

Should Ada have an implementation-independent means within the language 
which directly supports executing procedure variables which are statically 
checkable?  (I mean to imply here that appropriate run-time checks (which the
compiler can optimize away) would be performed to assure that the parameter 
and result type profiles of the procedure (or function) value match the call
which is made.)  I would answer yes.

What if the binding were dynamic?  (I assume no run-time checks here.)
I would again answer yes, provided that the syntax made it clear that the
model was being violated, as it currently does with Unchecked_Conversion and
pragma Inline.

I have spoken.

(Honesty compels me to admit, however, that the DoD has the last word.)


Cheers
-------