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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,29fe9a340e0d180d
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Depending on passing mechanism
Date: 1997/10/22
Message-ID: <EIFEst.BGL@world.std.com>#1/1
X-Deja-AN: 282345074
References: <x2hgal3jxa.fsf@moon.inf.fu-berlin.de>
 <hbaker-1710970939160001@10.0.2.1> <EIDpr3.ut@world.std.com>
 <62hpvc$1v5m@info4.rus.uni-stuttgart.de>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-10-22T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <62hpvc$1v5m@info4.rus.uni-stuttgart.de>,
Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:
>this thread has become very interesting due to
>a couple of valuable contributions.
>thank you all. You really have upvalued comp.lang.ada for a while.
>I am wondering why the SPARK approach (J.Barnes)
>has not been mentioned in this context.

I think it *was* mentioned.

The problem with SPARK is that it's such a *severe* subset of Ada.
Sure, it solves the problem of by-copy vs by-ref parameters, and others,
but it cuts out 90% of the language features.  So, although I think it's
a fine idea for safety-critical apps, I think it cuts out too much for
general-purpose apps.

- Bob