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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: The future of Spark . Spark 2014 : a wreckage Date: Thu, 18 Jul 2013 23:32:57 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1vc73wjwkqmnl$.gx86xaqy60u4$.dlg@40tude.net> <6pqhcwi0wuop.15v6h3g7gkto4.dlg@40tude.net> <1s6sw93u97355$.1n0205ucj6251.dlg@40tude.net> <1lhsyg46iz9jj.8jrvydqxt8l6.dlg@40tude.net> <1d4tuwlfdnz2j$.18l68s96x3vjj.dlg@40tude.net> <1rjye7dyn3vgk.66fbcca9y4zd.dlg@40tude.net> <1awbjaens2vca$.1asmpnthmmycl.dlg@40tude.net> <17i525dc26pat$.1octlzd41c8zm.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1374208378 24630 69.95.181.76 (19 Jul 2013 04:32:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 19 Jul 2013 04:32:58 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:16420 Date: 2013-07-18T23:32:57-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:17i525dc26pat$.1octlzd41c8zm.dlg@40tude.net... > On Wed, 17 Jul 2013 18:26:31 -0500, Randy Brukardt wrote: ... >>> Especially the ones crucial for exception contracts. How are you >>> going to prove the caller's contract not to raise? You could not without >>> non-sensual handlers. It would be like the idiotic "function must have a >>> return statement rule." >> >> You can only provide exception contracts if you have strong preconditions >> and constraints on the parameters. In the absense of that, you shouldn't >> be >> *allowed* to prove anything, because in doing so you force a strong >> coupling >> to the contents of the body. > > As I said. Useless. Then proof is beyond useless, it's downright dangerous. If you're right, no one should even think about it. ... >> It's impractical to have an Open that somehow encodes every possible >> sequence of Open-fall back-Open-Create that might come up. In the absense >> of >> that, you have to resort to complex program structures (it's not possible >> to >> declare objects with the right scope easily) or worse, > > It won't be any more complex than it is when handling exceptions > propagating out of Open. In fact it will be much simpler because you > forgot > the issue of closing the file on subsequent errors. I've never had the slightest "issue" with closing the file at the end. And certainly, there aren't "subsequent errors", because either the file gets opened eventually, or the whole routine is aborted (usually, the entire program is halted at the point, since failure to be able to write results -- no one needs to calculate results if you can't save them). Randy.