CVS difference for ais/ai-00288.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00288.txt

--- ais/ai-00288.txt	2004/04/06 19:57:04	1.5
+++ ais/ai-00288.txt	2006/05/12 20:28:32	1.6
@@ -614,3 +614,149 @@
+From: Robert A. Duff
+Sent: Wednesday, May 3, 2006,  8:39 AM
+Is anyone interested in discussing AI-288 and AI-375 here?
+AI-288 -- Pre- and Postconditions
+AI-375 -- Type and Package Invariants
+These were voted No Action for Ada 2005.
+AdaCore is thinking about implementing some sort of support for "programming
+by contract", and I thought these AIs might be a good starting point.
+Is there any interest in reviving these AIs for Ada 201X?
+Or perhaps just discussing the technical issues?
+Should I ask my questions here?
+Take it to ada-comment?
+Take it to private email amongst those interested?
+Keep quiet and go away?
+My first question is, why were these dropped?  Fatal technical flaws?
+Lack of time?  Too much "stuff" for Ada 2005?  Lack of interest from users?
+I believe AdaCore has customers interested in support for programming by
+contract, although we don't know exactly what they want, yet.
+From: Tucker Taft
+Sent: Wednesday, May 3, 2006,  8:56 AM
+The problems I remember:
+    1) Pascal thought the pragmas were ugggly.
+    2) There was no experience with using such pragmas with Ada.
+    3) There was a sense that these are only useful if they
+      are static rather than dynamic.
+I can't argue with (1) and (2), but (3) I don't agree with,
+because I think we have found until you have a way to say
+things dynamically, most people won't put in the effort to use
+them.  The static analysis tools can use them once they are
+there, even if they are originally defined as dynamic.  The
+inverse is not always true.
+The best answer for (2) is of course to create something and
+see how customers react.   So by all means, try them.  These
+are probably not appropriate discussion items for ARG until
+you have something specific to propose for standardization.
+Ada-comment or comp.lang.ada seems a better forum for the
+initial stages of your investigation.
+From: Pascal Leroy
+Sent: Wednesday, May 3, 2006,  9:30 AM
+> Keep quiet and go away?
+I can offer a bit of historical perspective here, since you didn't attend
+most of the meetings.
+This stuff was extensively discussed in Vienna in June 2002.  As I
+remember there was a feeling that these were interesting ideas, but that
+they were rather "experimental".  Surely no strong enthusiasm, and the
+discussion got bogged down because there was a wide variety of opinions as
+to what would be useful in this area.  In particular, as Tuck mentioned,
+there was a deep disagreement as to whether these things should be static
+or dynamic.
+Anyway, Tuck was asked to split the AI, and apparently he only did that in
+March 2004, immediately before the Phoenix meeting.  At that time we
+mostly in the business of finishing up the proposals that looked
+promising, and killing the rest.  At the Phoenix meeting Tuck proposed to
+vote the AIs No Action.
+Of course I always thought that the pragmas were ugly, but that cannot be
+the only explanation... ;-)
+From: Randy Brukardt
+Sent: Wednesday, May 3, 2006,  4:31 PM
+> My first question is, why were these dropped?  Fatal technical flaws?
+> Lack of time?  Too much "stuff" for Ada 2005?  Lack of interest
+> from users?
+Pascal answered this based on the record. Let me give you my personal
+I was originally very interested in these things.
+However, the more they were discussed, the more complicated they became.
+There was a decided problem of feeping creaturism, er, creeping featurism.
+The need to resolve expressions and names outside of their normal scope
+added complexity. The mechanism for getting the before-the-call parameter
+values meant significant runtime overhead (to copy the original values on
+every call) and a very difficult time for a one-pass compiler design to
+control that overhead. The rules for combining class-wide and specific
+conditions were so complex that Tucker never seemed to be able to explain
+them so the rest of us could understand. etc.
+Moreover, it was pointed out that it's possible to get the effect of pre and
+post conditions (and, to a lesser extent, invariants) with careful use of
+pragma Assert. That wouldn't be as convenient, of course, but it means that
+a sloppy solution isn't worth doing.
+So, it looked to me like we either needed a complex solution and convenient
+solution, or we shouldn't bother. But then you have to factor in the lack of
+experience -- no one has anything like these things available, so it wasn't
+clear whether they would get used or what the real requirements were.
+As such, it was a relief to me when Tucker motioned them to be voted No
+Action. (I was expecting a long drawn out discussion.)
+P.S. Some of the problems (especially the visibility ones) would be
+mitigated by putting most of the work in the body, perhaps by treating these
+things as operational attributes rather than pragmas. But let's have the
+technical discussion on Ada-Comment.
+From: Stephen Michell
+Sent: Wednesday, May 3, 2006,  8:41 PM
+It seems to me that 2 large obstacles in the way were
+1. The FM community was telling us that the features went too far and
+didn't go far enough at the same time. I think that the basic problems
+were that these productions would be available where statements are
+available right now, and aren't expressive enough to capture things that
+you may want to say in subprogram headers, ect, and can't look beyond
+the Ada scoping rules to express properties of the system that
+transcend  the scope.
+2. The dynamic nature of the constructs didn't really help the static
+analysis folks.
+It very well might be a good idea for a group like AdaCore to try this.
+It might make it easier to work out the issues and help get community
+acceptance once an implementation is in place.

Questions? Ask the ACAA Technical Agent