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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.24.71 with SMTP id s7mr4271657obf.42.1440112880097; Thu, 20 Aug 2015 16:21:20 -0700 (PDT) X-Received: by 10.182.60.130 with SMTP id h2mr84030obr.28.1440112880030; Thu, 20 Aug 2015 16:21:20 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!se8no7333878igc.0!news-out.google.com!f6ni423igi.0!nntp.google.com!x6no2675812igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 20 Aug 2015 16:21:19 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=75.161.23.130; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 75.161.23.130 References: <6952b70d-a9bc-4d0a-beb5-1cd38d6a3318@googlegroups.com> <9d3dc132-4e1a-4e9c-bcd4-82a42a73745f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9c4e49e0-732b-42f6-b52f-f0b379572889@googlegroups.com> Subject: Re: Problems with SPARK 2015 and XMLAda From: Shark8 Injection-Date: Thu, 20 Aug 2015 23:21:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:27537 Date: 2015-08-20T16:21:19-07:00 List-Id: On Thursday, August 20, 2015 at 2:36:09 PM UTC-6, Randy Brukardt wrote: > "Shark8" wrote in message > news:9d3dc132-4e1a-4e9c-bcd4-82a42a73745f... > ... > > As others have said, SPARK is about avoiding exceptions completely > > (because > > the relevant properties are proved) and therefore having exceptions in > > your SPARK > > code is not allowed. > > One use of exceptions is to signal errors with the parameters of a > routine -- essentially the failure of a precondition. Clearly, it is better > that such things are proved impossible, and thus such exceptions are not > needed in SPARK. This sort of exception is what I was thinking of. > > But another use of exceptions is to signal things that cannot be known at > compile time. How can you tell in advance whether the file Foobar.Txt exists > on your disk? Even a pretesting it is unreliable (it could be deleted > between the test and the usage); one has to report the error at runtime. > > SPARK forces such errors to be reported as error codes, and that's pure > evil. The problems with using error codes rather than exceptions to report > unlikely but possible errors are well-known, and forcing one to use that is > essentially junking decades of programming experience. I *really* despise error-codes -- Though with Ada you can make it a bit nicer by having an actual enumeration, throwing the function-call into a case-statement, and letting the compiler smack you when you forget to cover one of the codes. > > The lack of access types is similar; one has to emulate them using arrays in > SPARK, which is a 1950s programming technique. It's the sort of thing that > one uses Ada to get way from. Yes, it is. I wasn't aware of this 'feature' of SPARK. > > At least the SPARK team is aware of these limitations and considering ways > to mitigate them in future versions of SPARK. What I hate is people spinning > these as "features" rather than just a limitation of prover technology (and > to me, an indication that SPARK tries to do too much). I am hoping the SPARK team fixes some of those and it looks like they have been doing so -- just look at type-predicates: http://www.spark-2014.org/entries/detail/spark-2014-rationale-type-predicates