Re: Certified C compilers for safety-critical embedded systems

["Alexandre E. Kopilovitch" <aek@VB1162.spb.edu>]

Dmitry A. Kazakov wrote:

> > There is a well-known fact that human brain tends
> >to differentiate between result-oriented and "good next step" approaches, and
> >this has nothing specifically mathematical. Anyway, returning to programming,
> >I suppose you will not claim that there is absolutely no difference (except
> >syntax) between functional and procedural programming languages.
>
>That would be a point only if you were arguing for pure functions. Do
>you?

No. I'm against over-emphasising of "purity" for functions on the basis of
analogy with functions in mathematics.

A mathematical function is an abstraction, and it is very safe and thoroughly
guarded abstraction, while in programming nothing can be so abstract, and
therefore nothing can be (or should be) so "pure". For example (perhaps
somehow exotic, but nevertheless quite real), you can't entirely avoid
side-effects even if you use pure (in the programming sense) function: your
function does not change by itself anything in global space, but it just takes
some processor time for computation, and because of this some another task
reaches a particular point slightly later - and your whole program/system
loses significant data or even crashes or stalls.

So, my point is that the general notion of function in general-purpose
programming language should be a reasonable approximation of its mathematical
model, but not an attempt of exact translation of that mathematical notion
into programming. In general-purpose (and procedural) programming language
this notion should be placed somehow between that "pure" mathematical model
and the vague, but no less valuable notion of result-oriented subprogram.
It is for language designers to determine the exact position of the notion
within this range.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia