Re: In-Out Parameters for functions
From: Robert I. Eachus (rieachus_at_comcast.net)
Date: 02/29/04
- Next message: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Previous message: Stephen Leake: "Re: left-to-right (was In-Out Parameters for functions)"
- In reply to: Hyman Rosen: "Re: In-Out Parameters for functions"
- Next in thread: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Reply: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 29 Feb 2004 09:10:26 -0500
Hyman Rosen wrote:
> The section to which you refer defines a pair of "+" operations.
> I don't see how they cause any issues for l-to-r. And pragma Inline
> does not affect the semantics of a program, so again I don't see what
> the relevance is. I do agree that there seem to be unholy complexities
> lurking in the trade-offs between checking requirements and allowing
> optimization which could be exacerbated by requiring l-to-r.
You are getting there. Bob Mathis once told me a Lisp joke:
(defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1))
That really sums up the issue I was bringing up. The second function in
that particular pair of functions is probably defined by:
function "+"(Left : Storage_Offset; Right : Address) return Address is
begin return Right + Left; end "+";
-- with pragma Inline in the spec.
Now, when do you apply your left-to-right requirement, before or after
the pragma Inline has been applied? Since the pragma Inline probably
applies to both calls, I guess the answer has to be before the inlining.
Thinking some more about your proposal, now that I have looked at it
from all sides, a much more modest version seems reasonable: If an
expression contains two non-pure, non-predefined functions they must be
evaluated in canonical order instead of "some order." This would allow
compilers to do all their code motion in most cases, and only
expressions with two or more impure function calls would need to switch
off some of those optimizations. You could probably modify GNAT to
check the effects of that rule change out if you wanted to. (Or ask
your compiler vendor to put in a switch--the result of turning on the
switch would still be a legal implementation of Ada. Not that there is
a requirement that compiler switches work that way.)
Personally, as I said, I have written code that has to handle
Constraint_Error in some cases, and reraise it in others. In those
cases, for Ada 95, I not only have to break some expressions into two
parts, but insure that the parts are covered by different exception
handlers--in different packages. It is a pain to get that code right
according to the (current) Ada 95/2000 rules, but I don't think your
change would help. It is the permission in the last sentence of 11.6(6)
that is the real issue.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
- Next message: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Previous message: Stephen Leake: "Re: left-to-right (was In-Out Parameters for functions)"
- In reply to: Hyman Rosen: "Re: In-Out Parameters for functions"
- Next in thread: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Reply: Jon S. Anthony: "Re: In-Out Parameters for functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|