Re: Safety and power in languages

Darius Blasband <>
13 Feb 1996 18:08:54 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: Safety and power in languages (1996-02-04)
Re: Safety and power in languages (1996-02-09)
Re: Safety and power in languages truesoft! (1996-02-09)
Re: Safety and power in languages (1996-02-12)
Re: Safety and power in languages (Christian Fabre) (1996-02-13)
Re: Safety and power in languages (1996-02-13)
Re: Safety and power in languages (Darius Blasband) (1996-02-13)
Re: Safety and power in languages (Roger Barnett) (1996-02-14)
| List of all articles for this month |

From: Darius Blasband <>
Newsgroups: comp.compilers,comp.lang.ada
Date: 13 Feb 1996 18:08:54 -0500
Organization: EUnet Belgium, Leuven, Belgium
References: 96-01-116 96-02-026 96-02-057
Keywords: Ada, design (Daniel J. Salomon) wrote:

>Ada requires that all variant records have an explicit discriminant,
>whereas C union types do not even provide explicit discriminants.
>Requiring an explicit discriminant prevents a lot of errors, but I
>have written plenty of correct and reliable C code that did not have
>an explicit discriminant. In many algorithms the type of a union
>variable can be known from the context in which it is used. So you
>see, in Ada I am forced to write code in a certain way the prevent
>possible bugs, not necessarily to correct existing bugs.

I believe the major mistake you are making here is by ignoring the
difference between bug-free code, code which seems to work, code where
you know that everything is ok, code where "the context tells you it
is ok to use this unsafe structure this way", and formally correct
code, that is, code where the language and its semantics guarantee you
against some common mistakes. What would you trust better, a system
where the programmer is confident that he (or she) did not make any
mistake in using unions, or a system where the language ensures
formally that this kind of programming mistake cannot be occur without
being recognized by the environment as an exception, possibly at an
early stage.

We have exactly the same kind of argument with people who prefer
explicit deallocation to automatic garbage collectors. Of course, it
is possible that a program does handles its dynamic allocations
properly, and that no memory leak can occur, but personally, I feel
more confident when I don't rely on the *absence* of mistakes in an
unsecure system, but on a formally guaranteed property of the system I
am using.

>Another example is in the use of the C preprocessor. Preprocessors
>are bad practice and error prone; everyone knows that. But in C, I
>can write a simple preprocessor macro that will compute the maximum of
>any two numeric elements.
> # define MAX(x,y) ((x)>(y)?(x):(y))
>If I did apply MAX to an integer and a
>pointer to an integer, it would be an error, and Ada would protect me
>from that error. But I have rarely made that mistake, so Ada has just
>protected me from errors that I might have made, not errors that I did

I do not agree with you at all when you talk about the C preprocessor,
and I believe the key point of our disagreement lies in the last
sentence, not that I am such a fun of Ada, which I believe has
troubles of its own.

Quality is not just "it works". I believe that quality, in software as
well as in many other fields of engineering, should be: "it works and
I can guarantee formally that in the largest possible set of cases, it
will still work reasonably". Ada did not find errors you made, it gave
you absolute guarantee that you did not do these errors you might have


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.