Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

[Ludovic Brenta <ludovic.brenta@insalien.org>]

Peter Koch Larsen writes:
> "Ludovic Brenta" skrev i en meddelelse 
>> procedure Proc (A : in String) is
>> begin
>>   for J in A'Range loop
>>      J := J + 4; -- illegal, J is constant inside the loop
>>   end loop;
>>   Do_Womething_With (J); -- illegal, J no longer exists
>> end Proc;
>
> This is inherited from Pascal if I remember correctly. Of course,
> good C++ style is to declare your variable in the loop.

Most of Ada's syntax is inherited from Pascal.  In fact, Ada is
"Pascal done right", since Ada eliminated most of Pascal's problems
like separate compilation or the infamous "dangling else" problem. For
that matter, these problems also exist in C and C++.

It is true that, in ISO C++, loop variables declared in the for
statement are not visible outside the loop.  However, the library I
was working on did make use of the loop variable after the loop, and
none of our 4 or 5 different C++ compilers complained about it.

Which brings me to the general question: is there any
standard-compliant C++ compiler in existence?  Or are compilers only
"mostly compliant" or "close enough" or some other ill-defined term?

By contrast, consider Ada's formal validation process, which is also
an ISO standard (ISO/IEC 18009 - Ada: Conformity assessment of a
language processor).  In the 1980's, the DoD held the trademark "Ada",
and only validated compilers were allowed to call themselves "Ada
compilers".  Now, the rules are more lax, but all compilers in
existence pass the validation suite.  See:

http://www.ada-auth.org/acats.html

>> * conditions cannot mix "and" and "or" without parentheses.  Thus
>> there is no possibility that the programmer make wrong assumptions
>> about precedence of operators or order of evaluation.
>
> This seems ridiculous. I would expect a programmer to know the
> precedence rules or at least insert parentheses if they are in
> doubt.

This is the crux of the problem.  Assuming that the programmer "knows
the rules", "makes no mistakes" or "can be trusted" is a recipe for
disaster.  One of the principles in Ada's rationale is to make
everything explicit, rather than implicit.

>> * the type system, when used appropriately, makes it possible for
>> the compiler to find semantic errors in addition to just syntax
>> errors.  For example, you can declare that Numers_Of_Apples and
>> Numers_Of_Oranges cannot be mixed.  This is not possible with C++'s
>> typedef.
>
> I like that idea. It is possible using templates, of course. Is it
> general enough? If you replace "apples" with "weight" and "oranges"
> with "length", is it then permissible to multiply a length with a
> weight but not add the two together?

Yes:

type Weight is digits 8 range 0.0 .. 900.0;  -- 8 decimal digits of precision
type Length is digits 8 range 0.0 .. 1000.0;

Now these types are incompatible.  If you want to mix them, you need
to define the semantics and provide the appropriate operators:

type Weight_Length is digits 8 range 0.0 .. 900_000.0;

function "*" (Left : in Weight; Right : in Length) return  Weight_Length;

Since you don't provide "+", there is no way to add a weight to a
length.

For a more general discussion of physical quantities in Ada, see:

http://home.t-online.de/home/Christ-Usch.Grein/Ada/Universe.html

>> * conversions from floating point to integer types involve
>> rounding.  The rounding is precisely and deterministically defined
>> by the ISO standard for the Ada language.  Similarly,
>> floating-point and fixed-point types can be declared with known,
>> deterministic, guaranteed precision.
>
> This point sounds as if it restricts the environments where Ada can
> be used.

Do you mean that not all targets may implement the requested
precision?  That is true but it is not a language issue.  Ada
compilers are required to document which precision they support for
their targets.

And fixed-point types being really nothing more than integers, all
targets support them to some extent.

> I sort of like this one as well - although raising an exception
> seems to be to forgiving.

What other mechanism would you suggest?

> My conclusion is that there are some nice ideas out there, but that
> they mainly protect against the "sloppy" programmer.

It is a mistake to assume that the programmer makes no mistakes.
Mistakes are a given fact of the human nature.  Ada is designed with
this in mind.

A sloppy programmer will avoid Ada like the plague, because they
resent discipline in general and don't appreciate being taught
lessons.  A good software engineer will be attracted to Ada because
she is a powerful ally.

-- 
Ludovic Brenta.