Re: Press Release - Ada 2012 Language Standard Approved by ISO

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

On Wed, 26 Dec 2012 17:00:47 -0800 (PST), sbelmont700@gmail.com wrote:

> Consider the static case, where a subprogram has to specify a superset of
> all the specifications of subprograms it calls.

Not really. It specifies a conditional contract: "I rase E and whatever P
raises." I presume that P is explicitly stated, e.g. a callback or an
object passed.

> This will be of limited value, since you almost always end up being
> coupled to an API that you don't have control over (gtkAda, Claw, etc),

Ada API will certainly enjoy exception contracts. One of the nastiest
problems when using GtkAda is exceptions propagating into Gtk. Since GtkAda
is almost 100% user-defined Ada callbacks done from C, you *do* want to be
able to contract them not to raise anything.

> Secondly, the point is moot for OOP since the goal is to use classwide
> types.  Putting an exception specification on a parent type automatically
> restricts all the child types (which may not even be thought of yet, much
> less written) to following that same model, which is often not the case.

Exception contract must be inherited. It is governed by the LSP. Conditions
may be weakened, promises strengthened. Note that this does not mean that
the contract remains exactly same. For example, stream write might have the
contract "may raise Ada I/O exceptions." An implementation of a blocking
stream could exclude End_Error.

> Finally, IMHO, exceptions are NOT a property of the interface but of the
> implementation (we will likely have to agree to disagree on this).

This is evidently wrong because you can write an exception handler and make
the program's behavior dependent on whether the exception propagated.

> You can take a subprogram that works one certain way (and potentially
> raises one set of exceptions), and then rework the guts to work an
> entirely different way but produce the same output with the same inputs,
> and raises a whole new set of exceptions;

That would be another subprogram with another interface.

> e.g. if you allocate and free your variables instead of declaring them,
> that changes the subprograms interface because now you might raise
> STORAGE_ERROR?

Both interfaces have Storage_Error in the contract. No difference, also.

Regarding Storage_Error. The contract model should support conditional
exceptions. This is the case "I raise if you do" and for Storage_Error it
is "I don't raise if there is X free storage elements of stack and Y
elements of pool Z." The estimations would be very conservative of course
if you wanted it more portable. It is thinkable that some other measurement
unit could be deployed to make less architecture dependent. Though
Storage_Error handling is more interesting for embedded and RT
applications, which are natively less portable than others. Most users
would probably never contract Storage_Error anyway.

For recursive subprograms and other programs where memory consumption is
undecidable yet might be known from other sources (e.g. tests), the
programmer should be able to instruct the compiler using a pragma, that the
implementation satisfies the contract.

> I'm of the school of thought that says every subprogram has just one
> inherent contract when it comes to exceptions: as long as all the
> parameters and pre/post conditions are met, the subprogram will *never
> raise anything*.

Why not to state that contract, especially for those who belong to other
schools?

> Or, to put it another way, an exception is an indication that the
> contract with the interface has NOT been met.

See, there was a contract then. You are in a contradiction.

> You don't need to know which ones may or may not be raised, since as long
> as you meet the pre-conditions they won't ever happen anyway.

Yes. But you cannot put undecidable stuff into a precondition. This is the
backdoor through which End_Error and all other exceptions come in and make
themselves comfortable, at our expense of course.

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