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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31c63f07e48d5471 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-25 09:21:44 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: rod.chapman@praxis-cs.co.uk (Rod Chapman) Newsgroups: comp.lang.ada Subject: Re: Ada to 'C' parameter passing problem Date: 25 Feb 2003 09:21:44 -0800 Organization: http://groups.google.com/ Message-ID: References: <1ec946d1.0302191836.743eab91@posting.google.com> <1ec946d1.0302241553.24bc71f2@posting.google.com> NNTP-Posting-Host: 213.155.153.242 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1046193704 30865 127.0.0.1 (25 Feb 2003 17:21:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 Feb 2003 17:21:44 GMT Xref: archiver1.google.com comp.lang.ada:34568 Date: 2003-02-25T17:21:44+00:00 List-Id: mheaney@on2.com (Matthew Heaney) wrote in message news: > The purpose of a programming language is to make it easy for a > programmer to write programs. The language designer should not decide > by fiat how that should be done. Both the language and its designer > should stay out of the programmer's way, and assume that it is the > programmer himself who is in the best position to decide whether a > value-returning subprogram is appropriate for the problem at hand. Aha! I just can't resist steaming back in here... For high-integrity applications, "ease of writing programs" is hardly ever the most important thing. We're really interested in the ease, efficiency and cost of _verification_ of such programs. With that in mind as our primary design goal, then (as a language designer), we sometimes _do_ remove or constrain language features - the lack of function side-effects in SPARK is one such example. In this case we think it's worth it - the entire data-flow, information-flow, and VC-Generation facilities of SPARK depend on this particular property of the language (and many others...). We are acutely aware of the trade-off between expressive power and analysability/verifiability of the language, so we don't take these decisions lightly. Matt might find SPARK too restrictive for his interests and application domain, which is just fine. Many of our users think SPARK is about right. A few of them think it's too big! Vive la difference! All the best, Rod