Re: Build-in-place semantics? (Was: Ada design bug or GNAT bug?)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 4 Jul 2015 19:45:39 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:xtm95y6tqdo6$.1tfgl96oattey$.dlg@40tude.net...
>> On Sat, 04 Jul 2015 13:02:26 +0200, Jacob Sparre Andersen wrote:
>>
>>> Randy Brukardt wrote:
>>>
>>>> Probably not, build-in-place semantics isn't practical for all
>>>> non-limited types (think normal assignment, can't build-in-place
>>>> because if an exception occurs the original value has to be intact).
>>>
>>> A very sensible requirement, but wouldn't it be nice ...
>>
>> In my view it is not.
>>
>> Assignment is a syntax sugar of a primitive operation.
>>
>> If an operation propagates an exception there is no obligation on mutable
>> parameters except than type invariants (and post-conditions bound to the
>> exception).
>>
>> Compare it to a procedure with an in-out parameter.
> 
> A procedure with an in-out parameter shouldn't clobber the parameters on an 
> exception, either.

Yes. It must respect the type invariant.

> (Consider what happens for a by-copy parameter, of any 
> mode, when an exception is raised.) By-reference parameter passing 
> introduces the problem, and one could easily argue that it is the bug in the 
> language design (introduced for efficiency), not the difference in 
> requirements for assignment.

by-copy vs. by-reference is an implementation detail. The contract must
define the parameter state in the case of an exception. Since Ada lacks
exception contracts there is no way to do this.

But it is not the language's business define or imply such contracts.

> Also note that no parameter will be partially modified by a procedure unless 
> the procedure is actually written to do that. That's under the control of 
> the programmer. If the language allowed clobbering part of an object during 
> a failed assignment, no recovery would be possible (the object would be 
> "abnormal" and could never be used again until it is reinitialized -- that's 
> what happens for abort).

PL/1 exception model? No, recovery is easier if you do not rely on that.
You would just roll back the context until the latest safe state.

> That would make a lot of things hard to guarantee 
> short of using SPARK to prove exception absence.

It would make things easier if there were proper contracts on parameters of
all operations, assignment included.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de