Re: The future of Spark . Spark 2014 : a wreckage

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.