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

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

On Sat, 22 Dec 2012 23:38:21 +0100, Georg Bauhaus wrote:

> On 22.12.12 10:02, Dmitry A. Kazakov wrote:
> 
>>> In an ideal world, all of these "checks" will get made statically. Hopefully
>>> that's coming. In mean time, it's important to get programmers used to the
>>> idea of writing checks this way, so that future tools can make the checks
>>> statically (there is no hope of making checks statically if they are just
>>> written in natural language comments).
>>
>> OK, this is rather a tactical disagreement then. Ada's stance was
>> conservative, not eager adding features impossible to implement properly.
> 
> Rather, history tells that Ada has been seen by some as being just a little
> less improperly adventurous than Algol 68.

No, it is not same. Ada 83 compiler was difficult to build (then),
especially on a small machine, but there was little doubt about
practicability.

>> Because somebody (Georg) could readily base his design on the faulty.
> 
> Don't worry, my predicates tend to be pure, are used for debugging,
> and can be turned off/removed/left as documentation once the proofs
> have been checked. (Letting them stay can be a Good Thing if you need
> to prepare for the usual uncoordinated multi-player refactorings and
> quick fixes.)
> 
> The expressions don't have significant effects as measured by the purpose
> of the programs. For example, they may interrupt the normal flow, like
> explicit tests, they will send a mail message with some state information
> in it and ask for an optional user report. These reports are extremely helpful.
> 
> Checks can be written as if there was monitoring hardware, hence as
> if they did not even have a way of toggling any of the program's bits.

Actually, in a large project we deploy a similar stuff based GNAT-specific
support for tracing exceptions. It is a 50-50 game. In 50% of cases the bug
is reported by the monitor. In other 50% it causes a cascade of errors in
the monitor itself and around it, makes finding the cause more difficult
than without the monitor.

I think much, if mot all, boils down to exceptions, because it is
practically impossible to ensure safety of controlled objects against
unanticipated exceptions. It is non-testable and much too complicated for a
programmer to gasp. Contracted exceptions is an urgent need.

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