Re: In-Out Parameters for functions

["Robert I. Eachus" <rieachus@comcast.net>]

Hyman Rosen wrote:

(Others have done a good job of answering most of Hyman's points, but...)

>> To change the rules now would make lots of code obsolete.

> How can defining something which was previously unspecified
> make code obsolete? I'm not saying that Ada should change
> any specified behavior it currently has, I'm just saying
> that currently unspecified behavior should become specified.

Your assumption is that you could create a new rule which makes the new 
language a subset of the old one.  In one sense, that is easy.  Keep all 
the old legality rules and just add new ones.  Some existing programs 
will no longer compile, but if they do compile, they will have the same 
semantics as before.  I don't think you can come up with a set of rules 
like that without a lot of effort, but you are welcome to try.  The 
SPARK people certainly took that path and did it successfully.

But what if you keep the legality rules the same, and "just" change the 
semantics?  Then the problem is proving that existing code will have the 
same semantics under the new rules as under the old ones.

The current situation is that order of evaluation in Ada is partially 
specified.  I know of lots of code which was validated in part "by hand" 
and in part by tools which recognize the current Ada rules.  If the 
semantics change, recompiling this code makes all that analysis junk. 
(For example, red/black analysis in crypto code.)

If you want to reuse the existing code with new code, it is impractical 
to redo that analysis. (The code is often written so as to make the 
analysis easier.  But it won't necessarily be that easy for the new 
semantics.) So you either use a "project validated" compiler, or throw 
the code away.

I know what I would do, and changes in Ada that would make using "new" 
Ada compilers an issue are just what I said, a non-starter.

Notice that I and many other programmers know the existing Ada rules 
very well, and so does the SPARK Examiner.  That is one measure of how 
much would be thrown away by a major change to 11.6.

Incidently Ada 95 did change 11.6.  But it is worth noting that the 
changes were to resolve AI-315--remember that is an Ada 83 AI 
number--which we never found a fix for that wouldn't do too much damage 
to the language and to compilers.  Since Ada 95 was a much bigger change 
than Ada 0Y will be, we accepted that change then.  But not without a 
lot of soul searching.  It may have been that more soul-searching would 
have been worthwhile.  (The change is to define canonical semantics in 
terms of external effects.)  See 11.6(3) and 1.1.3(8-15).  In fact, I 
think that one change did more to slow the adoption of Ada 95 than any 
other change from Ada 83.

> There's certainly work involved in the compiler to make it
> evaluate things in a specific order. I personally would not
> classify it at the "go away" level. I know that GCC includes
> a Java compiler, so it at least has infrastructure for doing
> this at some level.

Once again, the problem is not with the compiler.  The whole idea of the 
entire HOLWG effort, even before GREEN became Ada, was to reduce the 
number of programming languages and compilers used by the DoD so that an 
infrastructure of support tools could be built around one or more core 
languages.  The HOLWG then decided that no existing language was 
sufficient as a base language for embedded system programming and tools. 
  That started a process that ended up creating Ada.

SPARK is one of the few non-compiler Ada tools that has reached the 
necessary critical mass to be able to say that it won't go away.  Other 
tools are part of the support infrastructure for each compiler, and 
should last at least as long as the compiler does.  An example in this 
category is gnatchop.  There are lots of other tools, such as GtkAda 
that have not reached the plateau, but if Ada usage keeps growing they 
will get there.  Or you can consider Rational's tools.  Rational made a 
business decision to develop those tools for several languages, 
primarily C++ and Ada. It might be interesting to find out what the 
relative sizes of the Ada and C++ markets are for Rational's tools, but 
from the original HOLWG viewpoint, it is irrelevant.  The tools are 
commercial, and the tools are available.  Anything else is gravy.


So in my opinion, any change to Ada which had the effect of invalidating 
  existing toolsets is a non-starter--and a bad idea.

Incidently there is nothing preventing anyone reading this from getting 
the GNAT compiler source and modifying it to support, say, in out 
parameters for functions.  But if you want to try a major change like 
the one Hyman is suggesting, I know I wouldn't have the energy or 
patience to try it.  A change like in out parameters for functions is 
localized, and even thought the localization may only be to a dozen 
places in the code, it shouldn't require modifying more than 5 KSLOC. 
Changing the order of evaluation rules would affect a substantial 
fraction of the entire compiler.  Call it reviewing 500 KSLOC and 
modifying 100 KSLOC.  Put out an RFP and I'll "No bid."  ACT might 
respond. ;-)


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush