Re: Contract checking in Ada

[Tapio Kelloniemi <spam17@thack.org>]

Randy Brukardt <randy@rrsoftware.com> wrote:
>"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
>news:d2hcqs$ct0$1@sparta.btinternet.com...
>> Tapio Kelloniemi wrote:
>> > But back to my original question, how could I implement programming by
>> > contract now when the designers have abandoned it in their great wisdom?
>>
>> And I don't think you're being very fair to the Ada0Y team. The effort
>> that has gone into/is going into it is still huge!

I did not mean that quite seriously, though I'm sad programming by contract
got rejected. If I did not appreciate the work of AdaXY teams, I would
not be here asking questions and wasting your time.

>> It would be great if there were dozens of volunteers to promote new
>> proposals but the sad truth is very few people are capable of writing an
>> amendment to the RM (and I certainly include myself is the 'not able'
>> camp). When people talk about "language lawyers" it isn't far from the
>> truth! The knowledge of the language has to be absolutely inside-out if
>> you want to be able to amend the actual language - not so much the
>> standard library but even that's tricky.

I agree. Looking at references of other languages reveals that some are
quite different from ARM, and not in the positive sense. Some I have read
are almost tutorials to the language with very few syntax descriptions.
Such manuals certainly are ambiguous in many places and some concepts
ar eleft unclear altogether.

>Yes, and they have to be very carefully reviewed, both for language issues
>and for implementation ones. (You don't want the new features to cause
>programs to run much slower -- the dreaded "distributed overhead"). These
>proposals kept getting messier and messier, and that played a part in their
>eventually being abandoned.

You don't have to tell, I've programmed in C++ (hopefully there aren't
any C++ programmers reading this...)

>For instance, Postconditions required a mechanism to get at the original
>values of parameters. Which meant that those values had to be saved
>somewhere. That would be a huge performance hit unless it is possible to
>tell in advance whether or not the original value would be required. We
>never had a proposal with that property (it really needs to be visible on a
>purely syntax basis; otherwise it can be too complex to figure out, as it
>would depend on name resolution and visibility).

Programming by contract features are IMHO disabled (speaking in free
software terminology) when a stable version is released, or in other
words, when a final product goes out. Xconditions are certainly a huge
performance hit, but not as much as inserting a break point at the
beginning and end of every subprogram in a debugger and then manually
examining parameter and result values, if program behaves oddly. All other
run-time checks are also expensive and that is why Ada provides a way to
disable them. Xconditions could actually speed up code that is considered
to be stable. This is because subprograms' parameters' validity checking
can be written as a precondition and does not need to be executed, when
the caller knows that a bad value cannot be passed in any situation.
For example subprograms of Ada.Strings's child packages have many checks for
their parameters' validity and as some of the subprograms are implemented
(in GNAT) in terms of others, the checks are doubled.

-- 
Tapio