CVS difference for ai05s/ai05-0188-1.txt

--- ai05s/ai05-0188-1.txt	2010/02/04 07:11:43	1.4
+++ ai05s/ai05-0188-1.txt	2010/02/16 23:58:25	1.5
@@ -222,6 +222,219 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Sent: Monday, November 16, 2009  3:53 PM
+
+>  procedure Add_To_Fruit_Salad(
+>     Fruit : in out Fruit_Type; Bowl : in out Bowl_Type)
+>     with
+>       Pre =>
+>         (case Fruit.Kind is
+>            when Apple => Fruit.Is_Crisp,
+>            when Banana => Fruit.Is_Peeled,
+>            when Pineapple => Fruit.Is_Cored);
+
+At first I liked the if-expressions: I have often wanted them, and had to
+simulate them with ugly work-arounds involving Boolean'Pos and the like.  Then
+of course I see the point about having a case-expression where you have the
+benefits of the coverage rules, and you preserve the symmetry among the choices.
+
+I am starting to feel uncomfortable, though, because there is no telling where
+this will stop.  Why not loop-expressions, for instance?
+
+procedure P (S : String)
+   with Pre => (for I in S'Range loop if S(I) > 'a' then false);
+
+Also, if you have a bunch of subprograms that all have the same pre- or
+post-conditions, are you going to repeat the same expression over and over
+again?  It seems to me that it's virtually impossible to reuse pre- and
+post-conditions.  That's not good.  As Bob likes to point out, the subprogram is
+the fundamental unit of code reuse, and it's unfortunate to have to give up on
+it.  What I would really like to write is something like:
+
+function Fruit_Is_Ready (Fruit : Fruit_Type) return Boolean renames -- Or whatever syntax.
+     (case Fruit.Kind is
+            when Apple => Fruit.Is_Crisp,
+            when Banana => Fruit.Is_Peeled,
+            when Pineapple => Fruit.Is_Cored);
+
+procedure Add_To_Fruit_Salad(
+     Fruit : in out Fruit_Type; Bowl : in out Bowl_Type)
+     with
+       Pre => Fruit_Is_Ready(Fruit);
+
+Of course, this would probably be more complicated to describe and to
+implement...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 16, 2009  4:06 PM
+
+...
+>	I am starting to feel uncomfortable, though, because there is  no
+>telling where this will stop.  Why not loop-expressions, for instance?
+
+That's AI05-0176-1 (Quantified expressions). Thank Ed for that one.
+
+>	Also, if you have a bunch of subprograms that all have the same
+> pre- or post-conditions, are you going to repeat the same expression
+>over and over again?  It seems to me that it's virtually impossible to
+>reuse pre- and post-conditions.  That's not good.  As Bob likes to
+>point  out, the subprogram is the fundamental unit of code reuse, and
+>it's  unfortunate to have to give up on it.  What I would really like
+>to write>  is something like:
+>
+>	function Fruit_Is_Ready (Fruit : Fruit_Type) return Boolean renames
+-- Or whatever syntax.
+>	     (case Fruit.Kind is
+>	            when Apple => Fruit.Is_Crisp,
+>	            when Banana => Fruit.Is_Peeled,
+>	            when Pineapple => Fruit.Is_Cored);
+
+That's AI05-0177-1, renaming of expressions as functions. Thank me for pushing
+this idea (although I think it might have been yours originally, many years
+ago).
+
+>	Of course, this would probably be more complicated to describe and
+>  to implement...
+
+Not really; it's the same as default expressions; the resolution is the same as
+preconditions. Both of those are already done.
+
+Anyway, is there any concern here that is not already on the agenda?? :-)
+
+It certainly is true that this creeping featurism is what is worrying me, and
+Bob, and several others. We'll probably have to do some work to reign that in.
+But at this stage, it is more important to have all of the ideas on table so we
+can weight them properly.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  4:09 PM
+
+> I am starting to feel uncomfortable, though, because there is no
+> telling where this will stop.  Why not loop-expressions, for instance?
+>
+> procedure P (S : String)
+>    with Pre => (for I in S'Range loop if S(I) > 'a' then false);
+
+Well indeed, this is the case of quantifiers, which are being actively
+considered, and indeed go along with the other forms.
+
+> function Fruit_Is_Ready (Fruit : Fruit_Type) return Boolean renames --
+> Or whatever syntax.
+>      (case Fruit.Kind is
+>             when Apple => Fruit.Is_Crisp,
+>             when Banana => Fruit.Is_Peeled,
+>             when Pineapple => Fruit.Is_Cored);
+>
+> procedure Add_To_Fruit_Salad(
+>      Fruit : in out Fruit_Type; Bowl : in out Bowl_Type)
+>      with
+>        Pre => Fruit_Is_Ready(Fruit);
+>
+> Of course, this would probably be more complicated to describe and to
+> implement...
+
+I'm a bit confused, I don't quite understand your suggested syntax here, but
+most certainly functional abstraction is possible in pre and post conditions.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, November 16, 2009  4:51 PM
+
+> It certainly is true that this creeping featurism is what is worrying
+> me, and Bob, and several others.
+
+Count me in
+
+> We'll probably have to do some work to reign that in. But at this
+> stage, it is more important to have all of the ideas on table so we
+> can weight them properly.
+
+Hmmm... Time for a "zero based budget" ?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 16, 2009  4:57 PM
+
+> It certainly is true that this creeping featurism is what is worrying
+> me, and Bob, and several others.
+
+Yeah, but I notice that we don't all agree on which of those creeps should be
+squelched.  E.g. I find case expressions significantly more useful than the +:=
+thing, and not that much more difficult to implement.
+
+I don't even agree with myself from week to week.  ;-)
+
+I think there's a lot on the table, though not as much as for Ada 2005.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 16, 2009  5:09 PM
+
+>> It certainly is true that this creeping featurism is what is worrying
+>> me, and Bob, and several others.
+>
+> Yeah, but I notice that we don't all agree on which of those creeps
+> should be squelched.  E.g. I find case expressions significantly more
+> useful than the +:= thing, and not that much more difficult to implement.
+
+Well not from where I sit. Case expressions is more like a days work, the +:= is
+more like an hour or two, but still in the very easy category.
+
+> I don't even agree with myself from week to week.  ;-)
+>
+> I think there's a lot on the table, though not as much as for Ada 2005.
+
+Well I am the first to get worried about an excessive implementation burden, or
+gratuitous upward incompatibilities (we still have customers staying away from
+Ada 2005, perhaps for ever, because of the limited return imcompatibility). But
+so far the 2012 changes proposed seem very much in reasonable range (I have not
+seen the real time stuff, which is effectively optional anyway).
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, November 17, 2009  12:56 AM
+
+> Anyway, is there any concern here that is not already on the agenda?? :-)
+
+Sorry for missing that this stuff was already being worked on.  I have a hard
+time keeping track of all the ideas that are thrown around.  And I certainly
+don't have a "big picture" of where this Amendment is going.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 17, 2009  12:05 PM
+
+> Anyway, is there any concern here that is not already on the agenda??
+> :-)
+>
+> Sorry for missing that this stuff was already being worked on.  I have
+> a hard time keeping track of all the ideas that are thrown around.
+> And I certainly don't have a "big picture" of where this Amendment is
+> going.
+
+It is going in the direction of safety, of course!  That means that
+pre/postconditions and type invariants are the most significant additions. To
+support these there is a new syntax for aspects of entities, and it follows that
+there is also improved syntax for predicates of various sorts: if-expressions,
+case expressions, quantified expressions.  Then (perhaps) there are new forms of
+constraints and non-contiguous discrete subtypes. More routine additions include
+new container types.
+
+New syntax for assignment operations is way down the list compared with the
+above, in my opinion.
+
+****************************************************************
+
 From: Bob Duff
 Sent: Wednesday, February 3, 2010  4:26 PM
 
@@ -422,13 +635,13 @@
 From: Ed Schonberg
 Sent: Wednesday, February 3, 2010  8:30 PM
 
-> I also have to wonder if this solution works very well for 
-> quantified_expressions, which also have to be referred to in many of 
-> these places (although the semantics is somewhat different). Would it 
-> look weird to combine two of the three new kinds of expressions, and 
+> I also have to wonder if this solution works very well for
+> quantified_expressions, which also have to be referred to in many of
+> these places (although the semantics is somewhat different). Would it
+> look weird to combine two of the three new kinds of expressions, and
 > not the third??
 
-The resolution rules for conditional expressions and case expressions are 
+The resolution rules for conditional expressions and case expressions are
 similar, but completely different from those of quantified expressions. The
 latter are always boolean, and there is nothing in the context that impacts
 the resolution of the container expression and the predicate, so they have