From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-08 19:36:42 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!fr.ip.ndsoftware.net!news.completel.fr!ircam.fr!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: Fri, 9 Jan 2004 06:47:32 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: <4r4qvvoo21a01nderfn4us3iv468vqas0m@4ax.com> NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1073619351 97041 80.67.180.195 (9 Jan 2004 03:35:51 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 9 Jan 2004 03:35:51 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: <4r4qvvoo21a01nderfn4us3iv468vqas0m@4ax.com>; from "Dmitry A. Kazakov" at Thu, 08 Jan 2004 09:35:55 +0100 X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:4238 Date: 2004-01-09T06:47:32+03:00 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