CVS difference for ais/ai-00414.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00414.txt

--- ais/ai-00414.txt	2005/02/08 02:36:55	1.1
+++ ais/ai-00414.txt	2005/02/08 07:12:41	1.2
@@ -331,4 +331,224 @@
 
 !appendix
 
+From: Jean-Pierre Rosen
+Sent: Tuesday, January 25, 2005  2:31 AM
+
+When you give a pragma No_Return to a subprogram, does it apply to
+subprograms derived from it?
+
+If you think of No_Return as being some kind of contract, that would
+certainly make sense, especially for dispatching calls.
+
+Hoping not to open YACOW (Yet Another Can Of Worms)
+
 *************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, January 25, 2005 11:34 AM
+
+Yes, No_Return should certainly apply to derived subprograms.
+This should behave the same way as other program-unit pragmas
+such as Inline (though I'm not sure where the rule is that
+implies inheritance of pragmas like this).
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 25, 2005 12:26 PM
+
+I'm not sure what you mean "derived subprograms."
+Certainly the implicitly declared inherited subprogram
+retains the No_Return, since it is just the same code.
+But I don't see any rule, nor would I expect there to
+be one, that says a subprogram that overrides such
+an implicitly declared inherited subprogram automatically
+inherits its program unit pragmas.  Inline being a good
+example where the subprogram in the parent type might
+be a good candidate for inlining, while the overriding
+would not.
+
+So I believe we need a special rule for No_Return, if
+we want it.  It does make sense to me that if a primitive
+procedure is declared No_Return, then so must be all
+of its overridings.  But I am a bit reluctant for it
+to be simply inherited.  I might rather require that the
+No_Return be explicit on each overriding.  It has
+a pretty dramatic effect, and I wouldn't want to have
+someone add it during maintenance to the top of a hierarchy,
+and suddenly discover that code deep down still compiled,
+but started raising Program_Error all over the place.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, January 25, 2005 12:42 PM
+
+Tucker Taft a ‚crit :
+> I'm not sure what you mean "derived subprograms."
+> Certainly the implicitly declared inherited subprogram
+> retains the No_Return, since it is just the same code.
+> But I don't see any rule, nor would I expect there to
+> be one, that says a subprogram that overrides such
+> an implicitly declared inherited subprogram automatically
+> inherits its program unit pragmas.
+
+That's the point.
+
+> So I believe we need a special rule for No_Return, if
+> we want it.  It does make sense to me that if a primitive
+> procedure is declared No_Return, then so must be all
+> of its overridings.  But I am a bit reluctant for it
+> to be simply inherited.  I might rather require that the
+> No_Return be explicit on each overriding.  It has
+> a pretty dramatic effect, and I wouldn't want to have
+> someone add it during maintenance to the top of a hierarchy,
+> and suddenly discover that code deep down still compiled,
+> but started raising Program_Error all over the place.
+
+So the rule should be that the pragma is required for every overriding
+of a "no_return" procedure, thus making a compilation error in the case
+you mention. That's a good idea.
+
+But now, what about the opposite way? Should we require that an
+overriding subprogram specifies No_Return *only if* the overridden
+subprogram has it? Actually, I can imagine that some primitive operation
+is not applicable to some derived type, and that you override the
+operation with one that always raises Program_Error...
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, January 25, 2005 12:46 AM
+
+> I'm not sure what you mean "derived subprograms."
+
+I'm not sure who the "you" you're referring to is. :)
+
+I interpreted that phrase as meaning inherited subprograms,
+not overridings.  However I suppose that J-P was probably
+referring to overridings since the answer seems obvious
+for inherited ones (though I'm still not sure there's a
+rule that actually implies that the pragma is inherited).
+
+> ... Inline being a good
+> example where the subprogram in the parent type might
+> be a good candidate for inlining, while the overriding
+> would not.
+
+Sure, there's certainly no rule for carrying pragmas over
+to overridings.
+
+> So I believe we need a special rule for No_Return, if
+> we want it.  It does make sense to me that if a primitive
+> procedure is declared No_Return, then so must be all
+> of its overridings.  But I am a bit reluctant for it
+> to be simply inherited.  I might rather require that the
+> No_Return be explicit on each overriding.  It has
+> a pretty dramatic effect, and I wouldn't want to have
+> someone add it during maintenance to the top of a hierarchy,
+> and suddenly discover that code deep down still compiled,
+> but started raising Program_Error all over the place.
+
+I agree that it shouldn't be inherited.  But I'm not convinced
+that it makes sense for it to be required to be given on overridings
+(or am I misunderstanding you?).  It seems that it should be fine
+for an overriding not to have No_Return semantics.  Why should
+we impose that restriction on extensions?
+
+*************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 25, 2005 12:30 AM
+
+I agree, although it might be nice to also have a way to say "this
+procedure never returns, but overridings can be different".
+This is the Eiffel problem that Tuck is fond of pointing out:
+there's no way to make a contract that applies to a particular
+procedure, as opposed to a whole tree of overridings.
+
+One probably wants No_Return to apply to access-to-subprogram types as
+well, but I suppose it's too late to bother with that for Ada 2005.
+
+> This should behave the same way as other program-unit pragmas
+> such as Inline (though I'm not sure where the rule is that
+> implies inheritance of pragmas like this).
+
+I don't remember any such general rule.
+
+As to Inline, I don't see why you would want it inherited.
+It's not a contract about the logical behavior of the thing
+-- it's just a statement that this thing is small enough (or whatever)
+to be inlined, which might be true or false independently for
+overridings.  And for dispatching calls, I don't think you're normally
+going to get inlining (although it's certainly possible in some cases).
+
+There's no pragma Out_Of_Line, so it would be somewhat questionable to
+have cases where inlining is requested implicitly (e.g. by
+inheritance).
+
+*************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 25, 2005 12:32 AM
+
+>   I might rather require that the
+> No_Return be explicit on each overriding.
+
+Yeah, that's an even better idea.
+
+Either way, the point is that the compiler can know about it at call
+sites -- including dispatching calls.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 25, 2005  1:21 PM
+
+> ...
+> One probably wants No_Return to apply to access-to-subprogram types as
+> well, but I suppose it's too late to bother with that for Ada 2005.
+> ...
+
+This seems certainly in the category of a desirable "tweak."  If we
+are adding a new pragma, we should make sure it applies to
+the appropriate kinds of entities.  No_Return is almost
+like a new calling convention, and those apply to access-to-subp
+as well (and are also required to be the same in overridings
+of dispatching ops, by the way).  So I would say we should
+have this apply to access-to-subp.  A No_Return acc-to-subp
+may only designated No_Return subps.  On the other hand,
+there is no problem for a "normal" (non-no-return) acc-to-subp
+designating a No_Return subp.
+
+Similarly, there should be no harm in overriding
+a non-no-return subp with a no-return one,
+but once you override with a no-return, then further
+overridings should also be no-return, for a tagged primitive.
+
+I suppose a formal subp should also allow a No_Return pragma,
+with corresponding rules (i.e. actual must be No_Return).
+
+*************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 25, 2005  2:32 PM
+
+> But now, what about the opposite way? Should we require that an
+> overriding subprogram specifies No_Return *only if* the overridden
+> subprogram has it?
+
+No, because lack of No_Return does not promise that the thing *will*
+return.  (And of course we can't very well say "raise P_E if so-and-so
+loops forever"!)
+
+>... Actually, I can imagine that some primitive operation
+> is not applicable to some derived type, and that you override the
+> operation with one that always raises Program_Error...
+
+No_Return promises no *normal* return; a No_Return procedure can raise
+whatever exceptions it likes (and, in fact, if it "tries" to return, it
+*will* raise an exception).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent