Re: GNAT packages in Linux distributions

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 5/15/10 11:30 AM, Dmitry A. Kazakov wrote:

> No type system can express the program semantics.

OK, lets keep this in mind.


> Compute should have the contract: if the sequence A,B is sorted then ...
> else Constraint_Error propagated. And of course, A, B is just an interval
> [B, A], and should be declared as such:
>
>     function Compute (X : Interval) return Number
>        with Precondition =>  True;

OK, I guess we'd have a To_Interval (A, B) function raising
constraint_error in case the programmer improperly passes A < B.
Which he has learned not to do from some comment that states
contractual obligations of client wishing to call To_Interval?



>>> Note, since your "preconditions" are not static,
>>> how can you know *what* they say, in order to do as they do?
>>
>> I can write my client code such that the preconditions are
>> true.
>
> Really? What about:
>
> pre : not HALT(p)

This is why I mentioned "not solve hard problems". I want to
keep making sense in my preconditions/comments.

> There is a reason why they aren't static.

Practically, yes, there is a reason why normal programming
cannot hope to rely on static analysis.


>>>> IOW, no redundant checks.
>>>
>>> No, it would be *inconsistent* checks. No program can check itself.
>>
>> DbC checks are not part of the (intended) program.  Monitoring can be
>> turned off and this should have no effect on program correctness.
>
> and thus on program execution. q.e.d.

The programs (with or without monitoring) are not too different
and hence will lead to a useful program construction process.
(Better exceptions.)


>> (a) there is nothing the programmer knows about valid Index_80
>> values (viz. the odd ones)
>
> They are *all* valid, that is the contract of Careful.

I guess we disagree here:  I think that a "programming into
exceptions" style leads to the universally applicable precondition
True, but otherwise keeps the programmer in the dark about
how to not make a subprogram raise.  OTOH, being more
specific (trying to explain additional "constraints")
seems helpful.  Here I recall

"No type system can express the program semantics."

Until Ada has a type system that can express expectations
better than predicates, I'll rather have stupid, weakly
typed predicates, supported by tools, than nothing.


   loop
     begin
        P(X);
        exit;
     exception when constraint_error =>
        X := find_another_x;
     end;
   end loop;



>> (b) there is no debugging hook that can be turned on
>> or off (monitoring the precondition X rem 2 = 1).
>
> Debugging hooks do not belong to code.

I guess my wording was too unspecific.  Call it tracing
automatism or whatever.


> You have to define "possible value":

In the sense of DbC:  values that client can pass without
violating the DbC contract.