Re: Safety and power in languages (Daniel J. Salomon)
9 Feb 1996 01:57:36 -0500

          From comp.compilers

Related articles
Re: Possible to write compiler to Java VM? (1996-01-29)
Safety and power in languages truesoft! (1996-02-02)
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: (Daniel J. Salomon)
Date: 9 Feb 1996 01:57:36 -0500
Organization: Computer Science, University of Manitoba, Winnipeg, Canada
References: 96-01-116 96-02-026
Keywords: design, Ada

Daniel J. Salomon <> wrote:
>Ada's philosophy seems to be, "When in doubt, forbid it." As a
>result, a programmer can spend a lot of time turning sensible safe
>code into code that religiously observes all of Ada rules.

truesoft! (Steve Witham) writes:
> Isn't it easier to think in a language from the start instead of
> starting from an illegal program and "turning [it] into" a legal
> program?

Let me give two concrete examples of what I am talking about.

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.

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))

The error proneness of preprocessors is amply demonstrated by the
abundance of parentheses, but this macro can still be used safely and
easily most of the time. Modern safe programming languages do not
provide preprocessors and instead try to provide equivalent
functionality with templates or generics. Using those two mechanisms,
one can define a MAX template that will accept two parameters of the
same type, and return the max of that type, or multiply overloaded
functions that handle all the possible combination of parameter types.
These replacements can usually take more skill to use, more source
code, and more effort to compile, and may not provide the full
polymorphism of the C macro. Thus simplicity of the preprocessor
approach was lost in order to protect programmers from errors that
they might make using macros. 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

The irony of this discussion is that I am a proponent of safer
languages myself. I have designed a language called Safer_C, and I
will be presenting a paper called "Using Partial Evaluation in Support
of Portability, Reusability, and Maintainability" at the International
Conference on Compiler Construction CC'96 in Sweden in April. This
paper proposes to use partial evaluation in place of a preprocessor
phase. My language is called "Safer_C" not "Safe_C" because I am
trying not to cripple or burden the language with safety measures. I
believe that my language keeps the power, fun an flexibility of C
while eliminating the possibility of 23 of the most common errors.
(It is at least as much work again to build a safe compiler as it is
to design a safe language, so the compiler is not ready for
distribution yet.)

Daniel J. Salomon -- salomon@cs.UManitoba.CA
              Dept. of Computer Science / University of Manitoba
              Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687

Post a followup to this message

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