Re: Specifying the order of ops on an ADT with aspects

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:91ab6070-fc9e-4575-a967-8fe43353ba26@36g2000yqu.googlegroups.com...
>AI05-0145-2 says 
>http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0145-2.txt?rev=1.4
>> This is based on the previous alternative AI05-0145-1. The
>> Pre/Post aspects are specified using the aspect_specification
>> syntax defined in AI05-0183-1. There is no message associated
>> with the failure of a precondition or postcondition check: it
>> was deemed that these annotations are intended for verification,
>> and that for debugging purposes the Assert pragma is sufficient.
>The last sentence is the most important for you topic.
>
>All providing I've really understood your question
>
>� intended for verification, and that for debugging purposes the
>Assert pragma is sufficient �

I think you guys miss the point of that statement. A Precondition that fails 
raises Assert_Error (unless suppressed, of course). That gets handled in the 
normal way, whatever your implementation does for unhandled exceptions. 
Nothing new here.

But the original proposal included an optional message string, similar to 
the one the Assert pragma has. We decided to drop that because programs that 
fail Preconditions are just wrong, and there is no need to go into detail 
*why* they're wrong.

I'd expect Janus/Ada to report something like:

** Unhandled Assert_Error - precondition check failed

In any case, Ada has nothing to say about how unhandled exceptions are 
reported.

We're working hard on a proposal to give the compiler enough information to 
be able to do static analysis of preconditions/postconditions, etc. We won't 
mandate that this time, but we surely want the possibility to exist --  
otherwise there is little value to specifying these over plain old Assert 
pragmas. (Perhaps next time we'll be able to mandate some static checking.)

                                  Randy.