* Re: In-Out Parameters for functions
2004-01-29 19:46 ` Hyman Rosen
@ 2004-01-29 20:23 ` Georg Bauhaus
2004-01-29 21:36 ` Hyman Rosen
2004-01-29 23:52 ` David Starner
` (2 subsequent siblings)
3 siblings, 1 reply; 203+ messages in thread
From: Georg Bauhaus @ 2004-01-29 20:23 UTC (permalink / raw)
Hyman Rosen <hyrosen@mail.com> wrote:
: In general, the compiler cannot know whether particular
: code has such order dependencies or not, and so cannot reliably
: warn of such uses.
True, however in general, i.e. in the presence of global state,
a _programmer_ cannot know what the results of evaluating
expressions in order will be. A reason is complexity of the
required reasoning, in particular in the presense of tasking.
-- Georg
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-29 20:23 ` Georg Bauhaus
@ 2004-01-29 21:36 ` Hyman Rosen
2004-01-30 17:39 ` Georg Bauhaus
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-01-29 21:36 UTC (permalink / raw)
Georg Bauhaus wrote:
> True, however in general, i.e. in the presence of global state,
> a _programmer_ cannot know what the results of evaluating
> expressions in order will be. A reason is complexity of the
> required reasoning, in particular in the presense of tasking.
What a puzzling statement! If a programmer cannt reason about
c := f1 + f2;
even knowing that f1 and f2 will be called left-to-right, how
can he reason about
a := f1;
b := f2;
c := a + b;
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-29 21:36 ` Hyman Rosen
@ 2004-01-30 17:39 ` Georg Bauhaus
2004-01-30 18:14 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Georg Bauhaus @ 2004-01-30 17:39 UTC (permalink / raw)
Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> True, however in general, i.e. in the presence of global state,
:> a _programmer_ cannot know what the results of evaluating
:> expressions in order will be. A reason is complexity of the
:> required reasoning, in particular in the presense of tasking.
:
: What a puzzling statement! If a programmer cannt reason about
: c := f1 + f2;
: even knowing that f1 and f2 will be called left-to-right, how
: can he reason about
: a := f1;
: b := f2;
: c := a + b;
He can't. Order won't help unless you assume that order
eases predicting the current global state and how it interacts
with f1 and f2 (or f2 and f1).
Thus order might help in some circumstances, however I don't see
the really big help it offers.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 17:39 ` Georg Bauhaus
@ 2004-01-30 18:14 ` Hyman Rosen
2004-01-30 19:32 ` Georg Bauhaus
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 18:14 UTC (permalink / raw)
Georg Bauhaus wrote:
> Thus order might help in some circumstances, however I don't see
> the really big help it offers.
As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
just as
cx, cy, cz : Coord := ReadCoord;
works. But the really big help is that the meaning of such code won't
silently change when changing some aspect of the environment. Of what
benefit is it to the programmer when the ARM allows things to happen
in arbitrary order?
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 18:14 ` Hyman Rosen
@ 2004-01-30 19:32 ` Georg Bauhaus
2004-01-30 20:51 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Georg Bauhaus @ 2004-01-30 19:32 UTC (permalink / raw)
Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> Thus order might help in some circumstances, however I don't see
:> the really big help it offers.
:
: As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
: Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
: just as
: cx, cy, cz : Coord := ReadCoord;
: works. But the really big help is that the meaning of such code won't
: silently change when changing some aspect of the environment. Of what
: benefit is it to the programmer when the ARM allows things to happen
: in arbitrary order?
(add p: Point := (x | y | z => ReadCoord); to the list of surprises.)
People coming from the substitution model of programming might
"feel like they know what's going on" (L. Wall, perlmod),
however this might be the opposite of helpful in writing
programs that use assignment not substitution, or that use "world",
with or without order.
It matches the tasking dizziness well.
But I won't insist, I'm only trying to see how this could make sense.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 19:32 ` Georg Bauhaus
@ 2004-01-30 20:51 ` Hyman Rosen
2004-01-30 23:25 ` Georg Bauhaus
2004-01-31 0:07 ` Robert I. Eachus
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 20:51 UTC (permalink / raw)
Georg Bauhaus wrote:
> People coming from the substitution model of programming...
> I'm only trying to see how this could make sense.
I'm trying to see how someone could believe that fixing an order of
evaluation doesn't make sense. Of what use is arbitrariness to the
semantics of the language?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 20:51 ` Hyman Rosen
@ 2004-01-30 23:25 ` Georg Bauhaus
2004-01-31 0:07 ` Robert I. Eachus
1 sibling, 0 replies; 203+ messages in thread
From: Georg Bauhaus @ 2004-01-30 23:25 UTC (permalink / raw)
Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> People coming from the substitution model of programming...
:> I'm only trying to see how this could make sense.
:
: I'm trying to see how someone could believe that fixing an order of
: evaluation doesn't make sense. Of what use is arbitrariness to the
: semantics of the language?
I had people in mind, not just programming languages.
You might say it makes sense to adapt one's reasoning to the
requirements of a programmaing language/style etc.
For predicting properties of object code this might be necessary
in addition to checking. However, do you define or design high
level languages to just produce object code in a systematic
manner or is there more to it? Like expressiveness, dealing well
with what people (not: Scheme fans, Ada fans, APL fans)
usually do when writing programs? Languages that suggest
ways of commanding a computer to "execute an idea"?
In the substitution model you don't have to worry about
the order of evaluation, that is, you reduce complexity.
However, the world has state, and no rollback, so the
substitution model may not work.
Consequence: In the presence of time dependence, learn to
"think from left to right" in addition to down the sequence
of instructions.
Alternative consequence: In the presence of time dependence, if you
want a specific order of elaboration, say so in the direction
of declarations and statements, but not when it comes to
"inputs" to "value creating items". (I admit that this is somewhat
artificial.)
If you say that the idea of substitution should not be a guideline
when variables can have changing values, you might want order of
evaluation to imply consistency with western wrinting direction in all
respects. I.e. I am weighting other aspects of source code constructs
less, like "a collection of inputs to a function where each
input is named" --conceptually the order of association is an addon
necessitated by that nasty time dependent statefulness of the world
in case there are globals or inputs or side effects.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 20:51 ` Hyman Rosen
2004-01-30 23:25 ` Georg Bauhaus
@ 2004-01-31 0:07 ` Robert I. Eachus
1 sibling, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-01-31 0:07 UTC (permalink / raw)
Hyman Rosen wrote:
> I'm trying to see how someone could believe that fixing an order of
> evaluation doesn't make sense. Of what use is arbitrariness to the
> semantics of the language?
This has been explained once in this thread, but here goes again. The
order of evaluation that Ada allows to be arbitrary is so that some
'common' optimizations such as common subexpression elimination and code
hoisting can be done. This trade-off was explicitly accepted because
without it, much of the constraint checking that Ada requires would be
too expensive, and everyone would turn it off. (In fact, in the
embedded world we often had to convince project management not to
mandate turning constraint checking off. It does no good for the
programmers to know that Ada constraint checking is essentially cost
free if you don't explain that to management as well.)
Let me give a simple example to explain this:
for I in A'Range loop
A(I) := B(I);
end loop;
Now 'obviously' you don't have to do the range check on A every time
through the loop, but what about B? You can check that the lower bound
is okay once, but it seems that you have to check against the upper
limit each time. Actually in Ada 95, you don't. I won't go into the
ramifications needed to explain this hear, because the real explanation
is that the programmer didn't ask for it, and we don't want to prevent
the compiler from handling this move the same way as:
A := B(A'First..A'Last);
If you really NEED the check to be repeated, write:
for I in A'Range loop
begin
A(I) := B(I);
exception
when Constraint_Error => Do_Something(I);
end;
end loop;
If A and B are Strings, you should now get a byte copy and the value of
I in the exception handler will reflect the first subscript to fail the
check.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-29 19:46 ` Hyman Rosen
2004-01-29 20:23 ` Georg Bauhaus
@ 2004-01-29 23:52 ` David Starner
2004-01-30 3:02 ` Robert I. Eachus
2004-01-30 9:53 ` Dmitry A. Kazakov
3 siblings, 0 replies; 203+ messages in thread
From: David Starner @ 2004-01-29 23:52 UTC (permalink / raw)
On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen wrote:
> I don't think you understand. As Ada stands now, it is perfectly
> legal to write code which has unspecified results due to order of
> execution.
Actually, I do understand that.
> Then some change
> occurs in the environment, such as changing optimization level,
> or changing platform, and now the compiler makes a different choice
> and the code stops working.
That's true, and not unique to this case. Not taking care of the size of
Integer or integers can cause the same problem. So can threading code.
> You cannot make the argument that raesonable care would prevent this.
> That is the same argument that C programmers make for the compiler not
> checking array bounds or pointer access, and Ada proponents roundly
> reject such arguments.
The difference is that with array bounds or pointer access, the compiler
stops and says you're doing something wrong. This is more analogues to
making array accesses silently wrap to prevent out of bound access; it may
be what the programmer wanted, but a lot of times it won't be, and it will
confuse maintainers who come afterwards.
> Once
> this is in place, then depending on the order of evaluation within an
> expression will be no more problematic than depending on the order of
> execution of a pair of statements, and will not be "buggy".
I don't think
a := f(x);
b := g(x);
c := a + b;
is much better than
c := f(x) + g(x);
if f(x) and g(x) make silent changes to significant global state. But
the first at least makes some indication that the order of operations is
important. This is not proper coupling; I hardly see why Ada should go out
of its way to support bad, unmaintainable code.
>As for its
> utility, I submit that code like this:
> Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is perfectly sensible once you forget that order of evaluation was ever
> an issue and accept left-to-right as the natural way of things. Why is
> this statement any worse than
> cx, cy, cz : Coord := ReadCoord;
> Point p := (x => cx, y => cy, z=> cz);
I don't think it is. I don't really approve of the second statement,
either. In any case,
for I := 0.0 .. 2.0 step 0.25 loop
could also be considered perfectly sensible, but most of the statements
that extension would let in wouldn't be considered sensible.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-29 19:46 ` Hyman Rosen
2004-01-29 20:23 ` Georg Bauhaus
2004-01-29 23:52 ` David Starner
@ 2004-01-30 3:02 ` Robert I. Eachus
2004-01-30 16:09 ` Hyman Rosen
2004-01-30 9:53 ` Dmitry A. Kazakov
3 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-01-30 3:02 UTC (permalink / raw)
Hyman Rosen wrote:
> David Starner wrote:
>
>> Why should buggy code work?
>
> I don't think you understand. As Ada stands now, it is perfectly
> legal to write code which has unspecified results due to order of
> execution. In general, the compiler cannot know whether particular
> code has such order dependencies or not, and so cannot reliably
> warn of such uses. Therefore, it's possible for such code to slip
> undetected into production, and to survive testing because the
> order chosen by the compiler is the "correct" one. Then some change
> occurs in the environment, such as changing optimization level,
> or changing platform, and now the compiler makes a different choice
> and the code stops working.
>
> You cannot make the argument that raesonable care would prevent this.
> That is the same argument that C programmers make for the compiler not
> checking array bounds or pointer access, and Ada proponents roundly
> reject such arguments.
>
> Therefore, the best thing to do is to eliminate the lack of specificity,
> so that a line of code will be executed in the same order always. Once
> this is in place, then depending on the order of evaluation within an
> expression will be no more problematic than depending on the order of
> execution of a pair of statements, and will not be "buggy". As for its
> utility, I submit that code like this:
> Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is perfectly sensible once you forget that order of evaluation was ever
> an issue and accept left-to-right as the natural way of things. Why is
> this statement any worse than
> cx, cy, cz : Coord := ReadCoord;
> Point p := (x => cx, y => cy, z=> cz);
What determines whether something is a bug? On many projects it is in
the mind of the programmer, and nowhere else. I prefer to work on
projects with defined and written testable requirements, and to allow
these to define what is a bug. If the SDP says to use SPARK, then any
dependence on evaluation order is a bug, and it will be caught by the
SPARK toolset. If the SDP says something else, that will either
establish guidelines that define functions with side-effects to be bugs,
or which make calling two functions with mutual side-effects a bug.
Any of the the later approaches are fine with me, and are consistent
with programming in Ada. But you have to expect that I will regard any
language revisions which attempt to change those bug definitions as a
non-starter. Notice that you are welcome to use SPARK if you want, and
in fact I have worked with it on occasion. But on other projects I have
worked on, other definitions of bugs have been used. To change the
rules now would make lots of code obsolete.
Going through and reevaluating the programs according to the new rules
is possible. But without an automated toolset it is very expensive. If
there are significant upward incompatibilities in Ada 0Y, expect most
compiler vendors to plan to provide such migration tools. Now think
about the effort required to develop the tools for your proposed change,
and go away. Note that SPARK is a subset of Ada, and such a toolset
does exist for SPARK, so I am not saying it is impossible. Just that
you are in effect defining a new language, and the market for that
language is currently served by SPARK and the SPARK toolset.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 3:02 ` Robert I. Eachus
@ 2004-01-30 16:09 ` Hyman Rosen
2004-01-30 16:31 ` Peter Amey
2004-01-31 1:03 ` Robert I. Eachus
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 16:09 UTC (permalink / raw)
Robert I. Eachus wrote:
> will be caught by the SPARK toolset...
> establish guidelines...
To be caught by a toolset requires whole-program analysis.
At the very least, this dooms people who are writing libraries
or generics. Establishing guidelines is no substitute for having
the language avoid problems. C has a guideline that you should
not index beyond the end of an array.
> To change the rules now would make lots of code obsolete.
How can defining something which was previously unspecified
make code obsolete? I'm not saying that Ada should change
any specified behavior it currently has, I'm just saying
that currently unspecified behavior should become specified.
> Now think about the effort required to develop the tools
> for your proposed change, and go away.
There's certainly work involved in the compiler to make it
evaluate things in a specific order. I personally would not
classify it at the "go away" level. I know that GCC includes
a Java compiler, so it at least has infrastructure for doing
this at some level.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 16:09 ` Hyman Rosen
@ 2004-01-30 16:31 ` Peter Amey
2004-01-30 19:20 ` Hyman Rosen
2004-01-31 1:03 ` Robert I. Eachus
1 sibling, 1 reply; 203+ messages in thread
From: Peter Amey @ 2004-01-30 16:31 UTC (permalink / raw)
Hyman Rosen wrote:
> Robert I. Eachus wrote:
>
>> will be caught by the SPARK toolset...
>
> > establish guidelines...
>
> To be caught by a toolset requires whole-program analysis.
> [snip]
Not so in the case of SPARK. The language design and the use of
annotations means we can find things like function side effects and
aliasing at the program unit level using computationally efficient
techniques. We can frequently find errors in programs that are not yet
complete enough to compile. That is why SPARK users typically run the
Examiner about 10 times as often as they run the compiler (and about a
million times as often as they run the debugger!).
See http://www.sparkada.com/downloads/sigada2001.pdf for an overview of
how this all works.
Peter
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 16:31 ` Peter Amey
@ 2004-01-30 19:20 ` Hyman Rosen
2004-02-02 10:39 ` Peter Amey
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 19:20 UTC (permalink / raw)
Peter Amey wrote:
>> To be caught by a toolset requires whole-program analysis.
>
> Not so in the case of SPARK.
As far as I know, SPARK has no way of calling procedures
except by explicitly mentioning their names. That is, there
are no procedure access variables, no generics, and no
dispatching. So it's no surprise that when you annotate a
declaration in enough detail to tell you what the body will
be doing, you can perform the analysis without seeing the
body. That's close to whole-program analysis in my book.
Also, SPARK doesn't allow side-effects in functions, so this
discussion is pretty moot from SPARK's point of view.
But Ada is not SPARK. Ada does have procedure access variables,
generics, dispatching, and side-effects, and the issues of
evaluation order are germane.
By the way, I read the paper to which you referred. What happens
in SPARK if I have
package Sensor
--# own in State;
is
function Value return Integer;
--# global State;
end Sensor;
and I try to write
delta : Integer := Sensor.Value - Sensor.Value;
Can I write a function, not a procedure, which will return
different sensor values each time? Can I use them multiple
times in an expression?
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 19:20 ` Hyman Rosen
@ 2004-02-02 10:39 ` Peter Amey
0 siblings, 0 replies; 203+ messages in thread
From: Peter Amey @ 2004-02-02 10:39 UTC (permalink / raw)
[snip]
>
> By the way, I read the paper to which you referred. What happens
> in SPARK if I have
> package Sensor
> --# own in State;
> is
> function Value return Integer;
> --# global State;
> end Sensor;
> and I try to write
> delta : Integer := Sensor.Value - Sensor.Value;
You get a static semantic error: SPARK only allows variables and
constants to be initialized by constant (i.e. fixed at compile time)
expressions. Functions cannot be used. (There are other reasosn for
this as well including avoidance of elaboration order dependencies).
>
> Can I write a function, not a procedure, which will return
> different sensor values each time? Can I use them multiple
> times in an expression?
>
No. There are special rules for volatile functions. They can only be
used directly in simple assignment or return statements, not in general
expressions.
Peter
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 16:09 ` Hyman Rosen
2004-01-30 16:31 ` Peter Amey
@ 2004-01-31 1:03 ` Robert I. Eachus
1 sibling, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-01-31 1:03 UTC (permalink / raw)
Hyman Rosen wrote:
(Others have done a good job of answering most of Hyman's points, but...)
>> To change the rules now would make lots of code obsolete.
> How can defining something which was previously unspecified
> make code obsolete? I'm not saying that Ada should change
> any specified behavior it currently has, I'm just saying
> that currently unspecified behavior should become specified.
Your assumption is that you could create a new rule which makes the new
language a subset of the old one. In one sense, that is easy. Keep all
the old legality rules and just add new ones. Some existing programs
will no longer compile, but if they do compile, they will have the same
semantics as before. I don't think you can come up with a set of rules
like that without a lot of effort, but you are welcome to try. The
SPARK people certainly took that path and did it successfully.
But what if you keep the legality rules the same, and "just" change the
semantics? Then the problem is proving that existing code will have the
same semantics under the new rules as under the old ones.
The current situation is that order of evaluation in Ada is partially
specified. I know of lots of code which was validated in part "by hand"
and in part by tools which recognize the current Ada rules. If the
semantics change, recompiling this code makes all that analysis junk.
(For example, red/black analysis in crypto code.)
If you want to reuse the existing code with new code, it is impractical
to redo that analysis. (The code is often written so as to make the
analysis easier. But it won't necessarily be that easy for the new
semantics.) So you either use a "project validated" compiler, or throw
the code away.
I know what I would do, and changes in Ada that would make using "new"
Ada compilers an issue are just what I said, a non-starter.
Notice that I and many other programmers know the existing Ada rules
very well, and so does the SPARK Examiner. That is one measure of how
much would be thrown away by a major change to 11.6.
Incidently Ada 95 did change 11.6. But it is worth noting that the
changes were to resolve AI-315--remember that is an Ada 83 AI
number--which we never found a fix for that wouldn't do too much damage
to the language and to compilers. Since Ada 95 was a much bigger change
than Ada 0Y will be, we accepted that change then. But not without a
lot of soul searching. It may have been that more soul-searching would
have been worthwhile. (The change is to define canonical semantics in
terms of external effects.) See 11.6(3) and 1.1.3(8-15). In fact, I
think that one change did more to slow the adoption of Ada 95 than any
other change from Ada 83.
> There's certainly work involved in the compiler to make it
> evaluate things in a specific order. I personally would not
> classify it at the "go away" level. I know that GCC includes
> a Java compiler, so it at least has infrastructure for doing
> this at some level.
Once again, the problem is not with the compiler. The whole idea of the
entire HOLWG effort, even before GREEN became Ada, was to reduce the
number of programming languages and compilers used by the DoD so that an
infrastructure of support tools could be built around one or more core
languages. The HOLWG then decided that no existing language was
sufficient as a base language for embedded system programming and tools.
That started a process that ended up creating Ada.
SPARK is one of the few non-compiler Ada tools that has reached the
necessary critical mass to be able to say that it won't go away. Other
tools are part of the support infrastructure for each compiler, and
should last at least as long as the compiler does. An example in this
category is gnatchop. There are lots of other tools, such as GtkAda
that have not reached the plateau, but if Ada usage keeps growing they
will get there. Or you can consider Rational's tools. Rational made a
business decision to develop those tools for several languages,
primarily C++ and Ada. It might be interesting to find out what the
relative sizes of the Ada and C++ markets are for Rational's tools, but
from the original HOLWG viewpoint, it is irrelevant. The tools are
commercial, and the tools are available. Anything else is gravy.
So in my opinion, any change to Ada which had the effect of invalidating
existing toolsets is a non-starter--and a bad idea.
Incidently there is nothing preventing anyone reading this from getting
the GNAT compiler source and modifying it to support, say, in out
parameters for functions. But if you want to try a major change like
the one Hyman is suggesting, I know I wouldn't have the energy or
patience to try it. A change like in out parameters for functions is
localized, and even thought the localization may only be to a dozen
places in the code, it shouldn't require modifying more than 5 KSLOC.
Changing the order of evaluation rules would affect a substantial
fraction of the entire compiler. Call it reviewing 500 KSLOC and
modifying 100 KSLOC. Put out an RFP and I'll "No bid." ACT might
respond. ;-)
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-29 19:46 ` Hyman Rosen
` (2 preceding siblings ...)
2004-01-30 3:02 ` Robert I. Eachus
@ 2004-01-30 9:53 ` Dmitry A. Kazakov
2004-01-30 17:06 ` Hyman Rosen
3 siblings, 1 reply; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-01-30 9:53 UTC (permalink / raw)
On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>David Starner wrote:
>> Why should buggy code work?
>
>I don't think you understand. As Ada stands now, it is perfectly
>legal to write code which has unspecified results due to order of
>execution.
Wrong. Here is ARM 4.5:
"...For a sequence of predefined operators of the same precedence
level (and in the absence of parentheses imposing a specific
association), an implementation may impose any association of the
operators with operands so long as the result produced is an allowed
result for the left-to-right association, but ignoring the potential
for failure of language-defined checks in either the left-to-right or
chosen order of association."
allowed result /= unspecified result
The results are specified, they are all possibile ones produced by all
possible combinations exectution sequences. There is nothing wrong
with that, after all some people are still writing multitasking
programs...
>In general, the compiler cannot know whether particular
>code has such order dependencies or not, and so cannot reliably
>warn of such uses. Therefore, it's possible for such code to slip
>undetected into production, and to survive testing because the
>order chosen by the compiler is the "correct" one. Then some change
>occurs in the environment, such as changing optimization level,
>or changing platform, and now the compiler makes a different choice
>and the code stops working.
Writting programs depending on evaluation order in a way that the
"correct" order is not specified, that is not a language problem.
Programmers should know what they are doing. Do you really believe
that tests will detect an "incorrect" order when specified by RM more
probably than when selected by the compiler? In my experience errors
like this are extremely difficult to detect, no matter whether an
order is specified by RM or not. This is why, [and for numerous other
reasons] I would like to see pure functions in Ada + procedures with
return giving all sorts of warnings when order is not *explicitly*
specified.
>You cannot make the argument that raesonable care would prevent this.
>That is the same argument that C programmers make for the compiler not
>checking array bounds or pointer access, and Ada proponents roundly
>reject such arguments.
True, this argument would be invalid. But the argument, derived from
Gries position, is that the order shall be specified explicitly if
relevant to the program semantics. In all cases where the program
semantics does not depend on the order, it shall never be specified.
Both under- and overspecification are wrong.
>Therefore, the best thing to do is to eliminate the lack of specificity,
>so that a line of code will be executed in the same order always. Once
>this is in place, then depending on the order of evaluation within an
>expression will be no more problematic than depending on the order of
>execution of a pair of statements, and will not be "buggy". As for its
>utility, I submit that code like this:
> Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
>is perfectly sensible once you forget that order of evaluation was ever
>an issue and accept left-to-right as the natural way of things. Why is
>this statement any worse than
> cx, cy, cz : Coord := ReadCoord;
I presume here the order is also arbitrary.
> Point p := (x => cx, y => cy, z=> cz);
Anyway there are many orders contradicting each other:
type Point is record
Z : Coordinate;
Y : Coordinate;
X : Coordinate;
end record;
[ + optionally, a nasty represenation clause stating some other, third
order ]
Is this order[s] irrelevant? Provided that programs are written by
idiots, I assure you that 50% of them would believe that keyed
associations will not override the native order of record fields. Or
do you think that the guessing the results of:
Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
Point P1 := (ReadCoord, ReadCoord, ReadCoord);
Point P1 := (Y => ReadCoord, others => ReadCoord);
should be blessed as a symphony of safety and maintainability?
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 9:53 ` Dmitry A. Kazakov
@ 2004-01-30 17:06 ` Hyman Rosen
2004-01-30 17:52 ` David Starner
` (4 more replies)
0 siblings, 5 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 17:06 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
>>it is perfectly legal to write code which has unspecified results
>>due to order of execution.
>
> Wrong. Here is ARM 4.5:
> allowed result /= unspecified result
That very same section says that
The two operands of an expression of the form X op Y,
where op is a binary operator, are evaluated in an
arbitrary order, as for any function_call
arbitrary order = unspecified result
If I have (pidgin Ada again!)
x : 0..1 := 0;
function f : integer is begin x := 1 - x; return x; end f;
r : integer := f - f;
Then Ada legally permits r to be 1 or -1. That's what I call
unspecified, i.e., no single result is required. In a particular
fixed environment, it is likely that the above code will always
return the same value. If this is done in production code rather
than in a contrived example, and the order dependency isn't so
apparent, it will seem that everything is fine. Then a change in
environment can make the opposite result appear, and things may
be broken.
Everyone here is saying "so don't do that", which is what we
C/C++ programmers always say, and which you Ada guys sneer at.
> Do you really believe that tests will detect an "incorrect" order
> when specified by RM more probably than when selected by the compiler?
I believe that once code is written, tested, and found to work, then
having the evaluation order chosen by the language means that it will
continue to work even when the environment changes. If the order is
selected by the compiler, then you have no such assurance. Surely
this is obvious?
> In my experience errors like this are extremely difficult to detect
With a defined rather than arbitrary order, this might no longer be
an error. Removing sources of uncertainty in the language is good.
> Both under- and overspecification are wrong.
Nevertheless, in conventional programming languages overspecification
is the rule, and it is what programmers are used to. It is left to the
compiler to rearrange things if it can prove that the result remains
correct by the rules of the language, just as in the section you quoted.
>> cx, cy, cz : Coord := ReadCoord;
> I presume here the order is also arbitrary.
No, it is not. See 3.3.1/7. The order is strictly left-to-right.
> 50% of them would believe that keyed associations will not override the
> native order of record fields.
I don't believe that for a second. Making up dumb statistics in order
to bolster an untenable position is silly.
> Or do you think that the guessing the results of:
> Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
> Point P1 := (ReadCoord, ReadCoord, ReadCoord);
> Point P1 := (Y => ReadCoord, others => ReadCoord);
> should be blessed as a symphony of safety and maintainability?
Yes, actually I very much think so, and there should be no guessing involved.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 17:06 ` Hyman Rosen
@ 2004-01-30 17:52 ` David Starner
2004-01-30 20:28 ` Hyman Rosen
2004-01-30 21:31 ` Alexandre E. Kopilovitch
` (3 subsequent siblings)
4 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-01-30 17:52 UTC (permalink / raw)
On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen wrote:
> If I have (pidgin Ada again!)
> x : 0..1 := 0;
> function f : integer is begin x := 1 - x; return x; end f;
> r : integer := f - f;
> Then Ada legally permits r to be 1 or -1. That's what I call
> unspecified, i.e., no single result is required. In a particular
> fixed environment, it is likely that the above code will always
> return the same value. If this is done in production code rather
> than in a contrived example, and the order dependency isn't so
> apparent, it will seem that everything is fine. Then a change in
> environment can make the opposite result appear, and things may
> be broken.
>
> Everyone here is saying "so don't do that", which is what we
> C/C++ programmers always say, and which you Ada guys sneer at.
Everyone uses arrays and pointers. They are a part of good code. So
Ada people sneer about people who ignore problems even good
programmers have. They don't sneer about unmaintainable code (because "the
order dependency isn't [...] apparent") that they could make deterministic
at the cost of good code. What happens when someone uses f-f later
assuming it will be 1? Or if someone changes the code not to call f-f and
fails to make the side effects that something else is depending on? This
is bad code, and needs to be fixed at the program level, not the language
level.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 17:52 ` David Starner
@ 2004-01-30 20:28 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-01-30 20:28 UTC (permalink / raw)
David Starner wrote:
> They don't sneer about unmaintainable code that they
> could make deterministic at the cost of good code.
The example I have previously posted,
p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not "unmaintainable", except that it is non-deterministic in
current Ada. On the other hand, the following code
cx, cy, cz : Coord := ReadCoord;
p : Point := (x => cx, y => cy, z => cz);
is perfectly deterministic. Is it unmaintainable? Perhaps. But the
point is that someone might innocently code the first case, most
likely in a less obvious way, and it might survive all checking
and testing, because such things do, just like buffer overflows
stay in C/C++ code. The "cost" to good code is a phantom, trotted
out as an excuse for maintaining the status quo.
> What happens when someone uses f-f later assuming it will be 1?
With a defined order of execution, if it wasn't 1 before it wouldn't
be 1 now, and the tests would fail, demonstrating the error to the
programmer. With an arbitrary order of execution, it will turn out
to be 1 in the debug build and -1 in the production build, returning
the wrong answer at the worst possible time.
> Or if someone changes the code not to call f-f and fails to make
> the side effects that something else is depending on?
Then the code will fail, and testing will show that it has failed.
> This is bad code, and needs to be fixed at the program level,
> not the language level.
Whether or not the code is bad, I believe that it can readily slip
through checks into production because it works by coincidence. It
cannot be fixed at the program level any more than array overflows
can be fixed at the program level.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 17:06 ` Hyman Rosen
2004-01-30 17:52 ` David Starner
@ 2004-01-30 21:31 ` Alexandre E. Kopilovitch
2004-02-01 4:10 ` Hyman Rosen
2004-01-31 5:27 ` Randy Brukardt
` (2 subsequent siblings)
4 siblings, 1 reply; 203+ messages in thread
From: Alexandre E. Kopilovitch @ 2004-01-30 21:31 UTC (permalink / raw)
To: comp.lang.ada
Hyman Rosen wrote:
> I believe that once code is written, tested, and found to work, then
> having the evaluation order chosen by the language means that it will
> continue to work even when the environment changes. If the order is
> selected by the compiler, then you have no such assurance. Surely
> this is obvious?
You must be surprised, but the right answer is "generally, NO". The situation
depends on kind of applications for which the language is aimed.
When you rely upon fixed (in the language) evaluation order you are risking
to make things non-commutative. And if those things are commutative in the
underlying theory then you are subjected to unexpected failure when some part
of your "environment" changes. And if evaluation order is fixed in the
language then you lose an opportunity to caught that potentially dangerous
non-commutativity by testing with various compilers and various optimization
levels. Moreover, those failures that happen because of this difference -
between a theory, which is based on commutativity, and a non-commutative
implementation, may be extremely hard to investigate, just because the reason
is located neither in theory nor in software implemention, but somehow between
them. So, by fixing order of evaluation you enhance the overall situation
for theoretically trivial applications, but worsen it for applications that
are substantially based on non-trivial mathethical/physical theories.
So, both decisions - to fix evaluation order in Java and not to do that in Ada
- are right, these languageas are extreme cases: Java is used primarily for
theoreticaly trivial applications, while Ada is often used for applications,
based on mathematically non-trivial theories.
> Nevertheless, in conventional programming languages overspecification
> is the rule, and it is what programmers are used to.
That's true about commodity, but Ada language too often is used for programming
things that aren't commodities in any reasonable sense, and this is Ada's
native land. Ada isn't a popular language, can't be, and don't strive to be
too popular; what is desired is to get as much as possible of proper audience,
but not much more.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 21:31 ` Alexandre E. Kopilovitch
@ 2004-02-01 4:10 ` Hyman Rosen
2004-02-01 21:05 ` David Starner
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-01 4:10 UTC (permalink / raw)
Alexandre E. Kopilovitch wrote:
> And if evaluation order is fixed in the language then you lose an opportunity
> to caught that potentially dangerous non-commutativity by testing with various
> compilers and various optimization levels.
I'm sorry, but this is abject nonsense. When you use a language that does not
specify evaluation order and does not require the implementation to document
evaluation order, you will gain absolutely zero knowledge about "dangerous
non-commutativity" whatever the heck that might even mean, no matter how much
testing you do on how many systems, becaus eyou have no way of knowing if any
of those systems did their evaluations in an order different from another.
> So, both decisions - to fix evaluation order in Java and not to do that in Ada
> - are right, these languageas are extreme cases: Java is used primarily for
> theoreticaly trivial applications, while Ada is often used for applications,
> based on mathematically non-trivial theories.
This is so nonsensical, it approaches the level of the Chewbacca defense.
You may choose to believe this if you like, and I won't even attempt to
argue with this line of reasoning. It would be like debating the mad.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-01 4:10 ` Hyman Rosen
@ 2004-02-01 21:05 ` David Starner
2004-02-01 21:55 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-01 21:05 UTC (permalink / raw)
On Sun, 01 Feb 2004 04:10:37 +0000, Hyman Rosen wrote:
> When you use a language that does not
> specify evaluation order and does not require the implementation to document
> evaluation order, you will gain absolutely zero knowledge about "dangerous
> non-commutativity" whatever the heck that might even mean
You won't gain knowledge by brute force, but it does permit certain
reasoning, formal and informal, about code that you can't do if the
language forces evaluation order.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-01 21:05 ` David Starner
@ 2004-02-01 21:55 ` Hyman Rosen
2004-02-02 2:20 ` David Starner
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-01 21:55 UTC (permalink / raw)
David Starner wrote:
> You won't gain knowledge by brute force, but it does permit certain
> reasoning, formal and informal, about code that you can't do if the
> language forces evaluation order.
Sure. The compiler can say "I can pick an arbitrary order, so obviously
the programmer doesn't care what the order is." It's just like in C++,
where the compiler says, "He's using this as the index, so he must know
wht he's doing." If the programmer did thsi by intention, then an
opportunity for optimization is exposed. If the programmer is in error,
then an opportunity for a bug is exposed. The question is whether the
potential gain in optimization outweighs the potential for error. I don't
believe the potential for optimization afforded by leaving order of
execution unspecified is significant at all.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-01 21:55 ` Hyman Rosen
@ 2004-02-02 2:20 ` David Starner
2004-02-02 14:36 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-02 2:20 UTC (permalink / raw)
On Sun, 01 Feb 2004 21:55:54 +0000, Hyman Rosen wrote:
> David Starner wrote:
>> You won't gain knowledge by brute force, but it does permit certain
>> reasoning, formal and informal, about code that you can't do if the
>> language forces evaluation order.
>
> Sure. The compiler can say "I can pick an arbitrary order, so obviously
> the programmer doesn't care what the order is."
But the human can also say that. He doesn't have to worry that the
programmer before him, knowing the evaluation rules, make a+b /= b+a.
> It's just like in C++,
> where the compiler says, "He's using this as the index, so he must know
> wht he's doing."
But Ada can do something about that. For this to be equivalent, you'd have
to be asking for Ada to always return 0 or A(A'First) if you used an index
out of range.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-02 2:20 ` David Starner
@ 2004-02-02 14:36 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-02 14:36 UTC (permalink / raw)
David Starner wrote:
> But Ada can do something about that. For this to be equivalent, you'd have
> to be asking for Ada to always return 0 or A(A'First) if you used an index
> out of range.
No, because in this case there is always a valid result to return,
since the results are merely unspecified (i.e., chosen from a legal
set of possible outcomes). Why do we want the compiler to pick an
arbitrary value instead of specifying which one it picks?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 17:06 ` Hyman Rosen
2004-01-30 17:52 ` David Starner
2004-01-30 21:31 ` Alexandre E. Kopilovitch
@ 2004-01-31 5:27 ` Randy Brukardt
2004-02-01 4:02 ` Hyman Rosen
2004-02-01 2:14 ` cl1motorsports
2004-02-02 9:31 ` Dmitry A. Kazakov
4 siblings, 1 reply; 203+ messages in thread
From: Randy Brukardt @ 2004-01-31 5:27 UTC (permalink / raw)
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1075482385.142744@master.nyc.kbcfp.com...
...
> That very same section says that
> The two operands of an expression of the form X op Y,
> where op is a binary operator, are evaluated in an
> arbitrary order, as for any function_call
>
> arbitrary order = unspecified result
Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
and that's what people here (usually) mean. "Unspecified" means not only is
*any* result allowed, but also that the implementer doesn't even need to
tell you what the result will be. "Implementation-Defined" is that any
result is allowed, but the implementer has to tell you which it is.
This case is "only" about a (usually small, often a singleton) set of
allowed results. In your example, returning "-2" isn't allowed (obviously).
I realize you are using the term informally, but I think you're confusing a
lot of people by using it.
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-31 5:27 ` Randy Brukardt
@ 2004-02-01 4:02 ` Hyman Rosen
2004-02-03 1:54 ` Randy Brukardt
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-01 4:02 UTC (permalink / raw)
Randy Brukardt wrote:
> Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
> and that's what people here (usually) mean. "Unspecified" means not only is
> *any* result allowed, but also that the implementer doesn't even need to
> tell you what the result will be.
That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
Certain aspects of the semantics are defined to be either
implementation defined or unspecified. In such cases, the
set of possible effects is specified, and the implementation
may choose any effect in the set. Implementations shall document
their behavior in implementation-defined situations, but
documentation is not required for unspecified situations.
So I would have to say you're wrong. Unspecifed behavior allows the
implementation to choose from a limited set of possible effects, not
from an unlimited one, and the implementation doesn't have to tell
you what it chooses.
> I realize you are using the term informally, but I think you're confusing a
> lot of people by using it.
Apparently, I was using it formally, and the confused people are confused :-)
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-01 4:02 ` Hyman Rosen
@ 2004-02-03 1:54 ` Randy Brukardt
2004-02-03 3:07 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Randy Brukardt @ 2004-02-03 1:54 UTC (permalink / raw)
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:pT_Sb.6670$bn1.3505@nwrdny02.gnilink.net...
> Randy Brukardt wrote:
> > Sorry, Hyman, but Ada has a very specific meaning for "unspecified
result",
> > and that's what people here (usually) mean. "Unspecified" means not only
is
> > *any* result allowed, but also that the implementer doesn't even need to
> > tell you what the result will be.
>
> That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
> Certain aspects of the semantics are defined to be either
> implementation defined or unspecified. In such cases, the
> set of possible effects is specified, and the implementation
> may choose any effect in the set. Implementations shall document
> their behavior in implementation-defined situations, but
> documentation is not required for unspecified situations.
>
> So I would have to say you're wrong. Unspecifed behavior allows the
> implementation to choose from a limited set of possible effects, not
> from an unlimited one, and the implementation doesn't have to tell
> you what it chooses.
I think you're misinterpreting the meaning of this paragraph. Only bounded
errors always give a set of possible results. There is an implied
requirement for sensible choices, but certainly the RM rarely if ever gives
a set of results for either I-D or unspecifed.
Try 13.9(11), for instance (Unchecked_Conversion). It says that the result
is I-D, but never says anything about the possible results (other than that
it may be abnormal!). I know of compilers that reject such conversions;
others do various masking operations; and still others raise exceptions.
That's pretty close to the entire set of possible results!
I note that the AARM notes say "Note that the ``set of possible effects''
can be ``all imaginable effects''; which seems to be the default case. So I
think that the only purpose of that phrase is to allow the RM to give a set
of possible results -- something it rarely if ever does.
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-01-30 17:06 ` Hyman Rosen
` (2 preceding siblings ...)
2004-01-31 5:27 ` Randy Brukardt
@ 2004-02-01 2:14 ` cl1motorsports
2004-02-02 9:31 ` Dmitry A. Kazakov
4 siblings, 0 replies; 203+ messages in thread
From: cl1motorsports @ 2004-02-01 2:14 UTC (permalink / raw)
i just started on this message, and i don't know ada very well, BUT
wouldn't the best solution be to have the compiler throw an error if a
parameterless function that returns a different value is used as a
parameter to a procedure or function call? It is
bad form to write code like that in the first place.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-01-30 17:06 ` Hyman Rosen
` (3 preceding siblings ...)
2004-02-01 2:14 ` cl1motorsports
@ 2004-02-02 9:31 ` Dmitry A. Kazakov
2004-02-02 14:33 ` Hyman Rosen
4 siblings, 1 reply; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-02 9:31 UTC (permalink / raw)
On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>Dmitry A. Kazakov wrote:
> >>it is perfectly legal to write code which has unspecified results
> >>due to order of execution.
>>
>> Wrong. Here is ARM 4.5:
>> allowed result /= unspecified result
>
>That very same section says that
> The two operands of an expression of the form X op Y,
> where op is a binary operator, are evaluated in an
> arbitrary order, as for any function_call
>
>arbitrary order = unspecified result
>
>If I have (pidgin Ada again!)
> x : 0..1 := 0;
> function f : integer is begin x := 1 - x; return x; end f;
> r : integer := f - f;
>Then Ada legally permits r to be 1 or -1. That's what I call
>unspecified, i.e., no single result is required.
Does the specification of f require single result? It does not,
because f could as well call to Random or ask operator for a value.
Moreover, there could be a concurrent task modifying x! So it is not
Ada, but you who didn't specify it. Should you have written down the
full contract of f, a user of f would know whether it is legal to use
f as above, or concurrently from different tasks etc. The real [Ada]
problem is not order, but that a malignantly impure f can be used as
if it were pure.
>In a particular
>fixed environment, it is likely that the above code will always
>return the same value. If this is done in production code rather
>than in a contrived example, and the order dependency isn't so
>apparent, it will seem that everything is fine. Then a change in
>environment can make the opposite result appear, and things may
>be broken.
Which means that the code is wrong.
>Everyone here is saying "so don't do that", which is what we
>C/C++ programmers always say, and which you Ada guys sneer at.
OK, according to your theory C++ is right requiring to specify
parameter passing mode: by-copy vs. by-reference. But it is just one
of many evil features of C++! Once per month reviewing code I detect
programmers passing constant containers by copy! They do it over and
over again. Imagine a test which would catch that? With some
exemptions Ada leaves that to the compiler. And yes, it is well
possible to write a program which will work if the compiler chooses
one mode and crash otherwise.
>> Do you really believe that tests will detect an "incorrect" order
> > when specified by RM more probably than when selected by the compiler?
>
>I believe that once code is written, tested, and found to work, then
>having the evaluation order chosen by the language means that it will
>continue to work even when the environment changes. If the order is
>selected by the compiler, then you have no such assurance. Surely
>this is obvious?
It is not. Because "found to work" /= "found correct". There is a hope
that a code dependent on execution order will continue to work so far
the order is not changed. But isn't it better to know that the code
remains valid for any order?
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-02 9:31 ` Dmitry A. Kazakov
@ 2004-02-02 14:33 ` Hyman Rosen
2004-02-02 15:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-02 14:33 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> Which means that the code is wrong.
> ...
> Because "found to work" /= "found correct".
> ...
> But isn't it better to know that the code remains valid for any order?
There's no question that the code is wrong. There's no question that
as the language stands, it would be better to know that it is valid
for any order. The problem is that wrong code which has been found
to work can slip out into production. We know this is the case in C
for array bounds and pointer access, exacerbated by the compiler not
checking for these kinds of errors, and I don't see why it should not
be the case for Ada errors not detected by the compiler.
Once this code has slipped out into production, what gain is there by
having it potentially break by a change in environment?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-02 14:33 ` Hyman Rosen
@ 2004-02-02 15:41 ` Dmitry A. Kazakov
2004-02-02 17:01 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-02 15:41 UTC (permalink / raw)
On Mon, 02 Feb 2004 09:33:21 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>Dmitry A. Kazakov wrote:
>> Which means that the code is wrong.
> > ...
> > Because "found to work" /= "found correct".
> > ...
>> But isn't it better to know that the code remains valid for any order?
>
>There's no question that the code is wrong. There's no question that
>as the language stands, it would be better to know that it is valid
>for any order. The problem is that wrong code which has been found
>to work can slip out into production. We know this is the case in C
>for array bounds and pointer access, exacerbated by the compiler not
>checking for these kinds of errors, and I don't see why it should not
>be the case for Ada errors not detected by the compiler.
It should be the case, but it does not imply fixing the order.
Semantically wrong code cannot be made correct by doing that. To
continue your analogy with bounds checks, it is like to allow wrong
array index, but to define the result of A [-99999999999] as 0. It is
not much better. Better is to check, which means checking for
order-dependent side effects.
Fixing and specifying does not solve the problem of knowing what and
how things are fixed. In C++ A & B | C is legal and specified, but I
do appreciate Ada for making A and B or C illegal.
>Once this code has slipped out into production, what gain is there by
>having it potentially break by a change in environment?
Wrong code should not go so far.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-02 15:41 ` Dmitry A. Kazakov
@ 2004-02-02 17:01 ` Hyman Rosen
2004-02-03 8:54 ` Dmitry A. Kazakov
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-02 17:01 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> Semantically wrong code cannot be made correct by doing that.
That's not true. If it happens that a defined evaluation order
would do what the programmer wanted, then the code would indeed
become correct.
> it is like to define the result of A [-99999999999] as 0
No, it's not nearly as bad, because in the case of evaluation order,
we are specifying one of a set of legal results, whereas for indexing
there is no legal result.
> Wrong code should not go so far.
But there is (nearly) nothing to be gained by forcing the code to be
considered wrong.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-02 17:01 ` Hyman Rosen
@ 2004-02-03 8:54 ` Dmitry A. Kazakov
2004-02-03 14:06 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-03 8:54 UTC (permalink / raw)
On Mon, 02 Feb 2004 12:01:19 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>Dmitry A. Kazakov wrote:
>> Semantically wrong code cannot be made correct by doing that.
>
>That's not true. If it happens that a defined evaluation order
>would do what the programmer wanted, then the code would indeed
>become correct.
I do not think so. + is commutative, if a programmer uses it so that
a+b /= b+a, he makes a semantical error. Later on, he may forget about
his mistake, a code viewer will be even not aware about it. So I treat
it as a *wrong* code. A wrong code may under some circumstances
function properly, false => true. You want to fix the circumstances, I
prefer to fix the code.
>> it is like to define the result of A [-99999999999] as 0
>
>No, it's not nearly as bad, because in the case of evaluation order,
>we are specifying one of a set of legal results, whereas for indexing
>there is no legal result.
The results are illegal, if different [*]. When a programmer writes:
x:=a+b, the postcondition of that is:
{ x=a+b & x=b+a }
so there is no legal way to make it dependent on the evaluation order.
>> Wrong code should not go so far.
>
>But there is (nearly) nothing to be gained by forcing the code to be
>considered wrong.
Yes, if that cannot be checked. As I always said, I wished to have
pure functions in Ada.
------
* Floating point numbers are intervals and equations become inclusions
and the postcondition will hold.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-03 8:54 ` Dmitry A. Kazakov
@ 2004-02-03 14:06 ` Hyman Rosen
2004-02-03 15:32 ` Dmitry A. Kazakov
2004-02-04 3:01 ` Alexandre E. Kopilovitch
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-03 14:06 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> + is commutative
Mathematics went beyond dogmatic statements like that many years ago.
Notice you didn't say that * is commutative. Very disingenuous.
> You want to fix the circumstances, I prefer to fix the code.
Once the circumstances are fixed, the code is no more broken
than if the operands were evaluated in sequential statements.
> The results are illegal, if different [*].
Can you point to where the ARM says so? I believe you are wrong.
> When a programmer writes: x:=a+b, the postcondition of that is:
> { x=a+b & x=b+a }
If I replace + with *, you would find no one agreeing with you if the
operands were matrices, for example.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-03 14:06 ` Hyman Rosen
@ 2004-02-03 15:32 ` Dmitry A. Kazakov
2004-02-03 16:11 ` Hyman Rosen
2004-02-04 3:01 ` Alexandre E. Kopilovitch
1 sibling, 1 reply; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-03 15:32 UTC (permalink / raw)
On Tue, 03 Feb 2004 09:06:52 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>Dmitry A. Kazakov wrote:
> > + is commutative
>
>Mathematics went beyond dogmatic statements like that many years ago.
>Notice you didn't say that * is commutative. Very disingenuous.
Well, on numbers with overflow + is as non-commutative as * for
matrices. Commutativity is not a property of the sign "+". And
compilers do not try to optimize user-defined types just because they
have "+" defined, I hope.
>> You want to fix the circumstances, I prefer to fix the code.
>
>Once the circumstances are fixed, the code is no more broken
>than if the operands were evaluated in sequential statements.
Nope, false => true, but this does not make false premise true.
>> The results are illegal, if different [*].
>
>Can you point to where the ARM says so? I believe you are wrong.
I didn't talk about ARM. However, it mentions mathematically correct
result. If a+b differs from b+a more than accuracy requirements allow,
it is no more mathematically correct.
>> When a programmer writes: x:=a+b, the postcondition of that is:
>> { x=a+b & x=b+a }
>
>If I replace + with *, you would find no one agreeing with you if the
>operands were matrices, for example.
For matrices * is not commutative. We are discussing commutative
operators.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-03 15:32 ` Dmitry A. Kazakov
@ 2004-02-03 16:11 ` Hyman Rosen
2004-02-03 23:04 ` David Starner
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-03 16:11 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> For matrices * is not commutative. We are discussing commutative
> operators.
Ada allows + to be a user-written function. When this is done,
the function receives the operands in the order written in the
code. The operation is commutative only if this function wants
it to be. And "we" are not discussing commutative operators.
You are, in raising all of these crypto-mathematical objections
to fixing an order of evaluation. I have yet to find any of these
objections at all compelling - your theories seem to have nothing
to do with the actual process of writing code in Ada, either as
it now stands or as I think it should.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 16:11 ` Hyman Rosen
@ 2004-02-03 23:04 ` David Starner
2004-02-03 23:38 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-03 23:04 UTC (permalink / raw)
On Tue, 03 Feb 2004 11:11:23 -0500, Hyman Rosen wrote:
> I have yet to find any of these
> objections at all compelling
The person who raised the argument and persists in arguing one side
doesn't find the counter-arguments compelling. Shocking.
> your theories seem to have nothing
> to do with the actual process of writing code in Ada, either as
> it now stands or as I think it should.
It violates the expectations of a maintaining programmer.
To run into this problem, you'd usually be writing clumsy, hard to follow
code that needs to be fixed, not patched at the language level.
Your solution papers over the problem instead exposing it and getting it
fixed in the code, like it should be and which is done with the array and
pointer examples you keep bringing up.
You have to test the production version of your software already. You
never know what different switches will do to your code whether so
authorized by the standard or not.
All those arguments have to do with the writing of code in Ada.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 23:04 ` David Starner
@ 2004-02-03 23:38 ` Hyman Rosen
2004-02-04 1:54 ` David Starner
` (3 more replies)
0 siblings, 4 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-03 23:38 UTC (permalink / raw)
David Starner wrote:
> The person who raised the argument and persists in arguing one side
> doesn't find the counter-arguments compelling. Shocking.
There are plenty of times where I am convinced that a position I hold
has compelling counter-arguments. This is not one of them. I have yet
to hear why a deliberate ambiguity is better than a definite order.
> It violates the expectations of a maintaining programmer.
So your point is that the language should increase the possibility of
error instead? This just makes no sense. I really get the sense that
people are clinging desperately to "we've always done it this way".
> To run into this problem, you'd usually be writing clumsy, hard to follow
> code that needs to be fixed, not patched at the language level.
To belabor the point once more,
p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not clumsy or hard to follow, merely wrong in the status quo.
> Your solution papers over the problem
My solution makes it no longer be a problem.
> the array and pointer examples you keep bringing up.
I haven't brought them up in the context of Ada, only C/C++.
> You have to test the production version of your software already. You
> never know what different switches will do to your code whether so
> authorized by the standard or not.
True. But that doesn't mean that errors couldn't slip in anyway.
Errors that could be prevented at no cost to the programmer.
> All those arguments have to do with the writing of code in Ada.
I don't find that compelling :-)
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-03 23:38 ` Hyman Rosen
@ 2004-02-04 1:54 ` David Starner
2004-02-04 14:54 ` Hyman Rosen
2004-02-04 3:56 ` Alexandre E. Kopilovitch
` (2 subsequent siblings)
3 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-04 1:54 UTC (permalink / raw)
On Tue, 03 Feb 2004 18:38:26 -0500, Hyman Rosen wrote:
> David Starner wrote:
>> The person who raised the argument and persists in arguing one side
>> doesn't find the counter-arguments compelling. Shocking.
>
> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.
You're still far from an impartial judge.
>> It violates the expectations of a maintaining programmer.
>
> So your point is that the language should increase the possibility of
> error instead? This just makes no sense.
It shouldn't make things right just because it can. It should make
things right because they are logically right.
>> To run into this problem, you'd usually be writing clumsy, hard to follow
>> code that needs to be fixed, not patched at the language level.
>
> To belabor the point once more,
> p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is not clumsy or hard to follow, merely wrong in the status quo.
I have some pieces of code in response:
for I in 0.0 .. 1.0 step 0.25
is not clumsy or hard to follow, merely wrong in the status quo. But
making it right would bring in a lot of other stuff that won't work right.
x : 0..1 := 0;
function f : integer is begin x := 1 - x; return x; end f;
r : integer := f - f;
This isn't the clearest bit of code in the first place; on first glance, I
want to say that r is 0. I have to read the implementation details of f to
figure out what's going on. If it were
x: 0..1 = 0;
function f (z : integer) : integer is begin
x := x - z;
return x - z;
end f;
r: integer = f (x);
then we would have stepped into another of Ada's constructive ambiguities,
the fact that x may have been passed by copy or by reference. In a
real-life program, the same code that produces the first will quite
possibly run into the second problem. And if you don't, that doesn't mean
that the maintainer, who doesn't understand the program as well, won't.
>> Your solution papers over the problem
>
> My solution makes it no longer be a problem.
In any real program, diddling with a bunch of global variables is likely
to be hard to maintain and hard to reason about. Any thing that assumes
that the interpretation order of a line is left to right is going to be
adding sequence points where most languages don't have them and most code
doesn't have them and is going to be surprising to a maintainer, and
probably missed without comments.
>> the array and pointer examples you keep bringing up.
>
> I haven't brought them up in the context of Ada, only C/C++.
You've mentioned how they differ between Ada and C. But it's different to
make something an loud error and make it legal.
> True. But that doesn't mean that errors couldn't slip in anyway. Errors
> that could be prevented at no cost to the programmer.
And this could cause errors, by making things legal that are hard to
reason about and actually program with. And there's a cost to the
programmer, because it's a loss of an optimization opportunity and hence a
slower program at the end.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-04 1:54 ` David Starner
@ 2004-02-04 14:54 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 14:54 UTC (permalink / raw)
David Starner wrote:
>> p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
>
> I have some pieces of code in response:
> for I in 0.0 .. 1.0 step 0.25
Is this currently legal in Ada? Remember that my example is.
> the fact that x may have been passed by copy or by reference.
OK, I accept that there are more ambiguity issues than I have
been cnsidering. I suppose you object to getting rid of those too?
> In any real program, diddling with a bunch of global variables is likely
> to be hard to maintain and hard to reason about.
But using functions that read input is not hard to reason about.
BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);
Someone might reasonably think that the above line of code should fill
the array with sensor readings in order. You can tell him that it won't
work that way, but you can hardly say that he had no right to expect that
it would.
> sequence points where most languages don't have them
Java does, and many people are now exposed to that.
The Java language refernce manual also recommends not writing code
which exploits this, though, so that's one for your side. I think
it's just atavistic dread from the reptillian hindbrain.
> it's a loss of an optimization opportunity
But it's not, except for programs which are now exhibiting unspecified
behavior. If an expression has only one value regardless of execution
order, then the compiler will be free to evaluate it in any order.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 23:38 ` Hyman Rosen
2004-02-04 1:54 ` David Starner
@ 2004-02-04 3:56 ` Alexandre E. Kopilovitch
2004-02-05 13:32 ` Hyman Rosen
2004-02-04 7:00 ` Vinzent 'Gadget' Hoefler
2004-02-04 10:28 ` Stuart Palin
3 siblings, 1 reply; 203+ messages in thread
From: Alexandre E. Kopilovitch @ 2004-02-04 3:56 UTC (permalink / raw)
To: comp.lang.ada
Hyman Rosen wrote:
> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.
Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
earlier - I thought that you wanted to understand. So, here is a compelling
argument: consider a deliberate ambiguity in choosing of the next leader of
a country in democratic societies, and compare it with quite definite order
of that in absolute monarchies and totalitarian (Communists and others) regimes.
Which mode you like better?
But if you want purely scientific/technical and at the same time compelling
and condensed argument then I must disappoint you - you have very little
chance for getting it for free, simply asking for it - in this case. For free
you can get a hint only, and you already refused it. Well, you have an option: turn to
ARA or to some Ada-related vendor and ask them whether they can and will
supply you a compelling argument on this matter for $$$. Perhaps they will agree.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 3:56 ` Alexandre E. Kopilovitch
@ 2004-02-05 13:32 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-05 13:32 UTC (permalink / raw)
Alexandre E. Kopilovitch wrote:
> Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
> earlier - I thought that you wanted to understand. So, here is a compelling
> argument: consider a deliberate ambiguity in choosing of the next leader of
> a country in democratic societies, and compare it with quite definite order
> of that in absolute monarchies and totalitarian (Communists and others) regimes.
> Which mode you like better?
>
> But if you want purely scientific/technical and at the same time compelling
> and condensed argument then I must disappoint you - you have very little
> chance for getting it for free, simply asking for it - in this case. For free
> you can get a hint only, and you already refused it. Well, you have an option: turn to
> ARA or to some Ada-related vendor and ask them whether they can and will
> supply you a compelling argument on this matter for $$$. Perhaps they will agree.
"Ladies and gentlemen of the supposed jury, I have one final thing I want you
to consider: this is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk,
but Chewbacca lives on the planet Endor. Now, think about that. That does not
make sense!
"Why would a Wookiee -- an eight foot tall Wookiee -- want to live on Endor with
a bunch of two foot tall Ewoks? That does not make sense!
"But more importantly, you have to ask yourself: what does that have to do with
this case? Nothing. Ladies and gentlemen, it has nothing to do with this case!
It does not make sense!
"Look at me, I'm a lawyer defending a major record company, and I'm talkin' about
Chewbacca. Does that make sense? Ladies and gentlemen, I am not making any sense.
None of this makes sense.
"And so you have to remember, when you're in that jury room deliberating and
conjugating the Emancipation Proclamation... does it make sense? No! Ladies and
gentlemen of this supposed jury, it does not make sense.
"If Chewbacca lives on Endor, you must acquit! The defense rests."
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 23:38 ` Hyman Rosen
2004-02-04 1:54 ` David Starner
2004-02-04 3:56 ` Alexandre E. Kopilovitch
@ 2004-02-04 7:00 ` Vinzent 'Gadget' Hoefler
2004-02-04 14:57 ` Hyman Rosen
2004-02-04 10:28 ` Stuart Palin
3 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-04 7:00 UTC (permalink / raw)
Hyman Rosen wrote:
> I have yet
>to hear why a deliberate ambiguity is better than a definite order.
Because it is better to remove the ambiguity instead of making it look
like something else when in fact it isn't.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 7:00 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 14:57 ` Hyman Rosen
2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 14:57 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Because it is better to remove the ambiguity instead of making it look
> like something else when in fact it isn't.
But Ada doesn't necessarily warn you that such an ambiguity exists,
so it might wind up not getting removed.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 14:57 ` Hyman Rosen
@ 2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
2004-02-04 15:52 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-04 15:19 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> Because it is better to remove the ambiguity instead of making it look
>> like something else when in fact it isn't.
>
>But Ada doesn't necessarily warn you that such an ambiguity exists,
>so it might wind up not getting removed.
Well, IMO it doesn't get removed just by fixing the evaluation order,
either. It still is wrong code and as such it is the *code* that has
to be fixed.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 15:52 ` Hyman Rosen
2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
2004-02-04 19:58 ` David Starner
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 15:52 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Well, IMO it doesn't get removed just by fixing the evaluation order,
> either. It still is wrong code and as such it is the *code* that has
> to be fixed.
What is it about definite order of evaluation that you and so
many others find intrinsically evil?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:52 ` Hyman Rosen
@ 2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
2004-02-04 17:11 ` Hyman Rosen
2004-02-04 19:58 ` David Starner
1 sibling, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-04 16:36 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> Well, IMO it doesn't get removed just by fixing the evaluation order,
>> either. It still is wrong code and as such it is the *code* that has
>> to be fixed.
>
>What is it about definite order of evaluation that you and so
>many others find intrinsically evil?
Because it forces the programmer to think about optimization instead
of thinking about readability.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:52 ` Hyman Rosen
2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 19:58 ` David Starner
1 sibling, 0 replies; 203+ messages in thread
From: David Starner @ 2004-02-04 19:58 UTC (permalink / raw)
On Wed, 04 Feb 2004 10:52:14 -0500, Hyman Rosen wrote:
> What is it about definite order of evaluation that you and so
> many others find intrinsically evil?
Have you ever studied functional programming? I think part of the
objection is the concept that pure functional programming is the ideal and
that we differ from that for efficiency and a closer mapping to the
hardware.
Also, half the examples have been horrible code that should never be
written. So much of the code enabled by this feature can't be fixed
to use it without a program-wide analysis of the problems, wherein it
would be just as easy to fix the code not to depend on evaluation order.
> OK, I accept that there are more ambiguity issues than I have
> been cnsidering. I suppose you object to getting rid of those too?
That would require major surgery to the language that would leave it
backwardly-incompatible or require the compiler to do stupid slow things.
If you want Java, you know where to find it.
In any case, you have a huge group of ambiguity issues around threads.
It's inherent in the system. If you're worried about your compiler
changing evaluation order at compile time, wait until your program starts
behaving erratically at run time because you made the same mistakes.
> But using functions that read input is not hard to reason about.
> BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);
Which it is easy to warn about and simple to fix.
> But it's not, except for programs which are now exhibiting unspecified
> behavior. If an expression has only one value regardless of execution
> order, then the compiler will be free to evaluate it in any order.
If the compiler can prove that, which is easier said then done. At best,
it will slow down compilers at compile-time, proving what they could
assume before, and slow down programs at run-time when they couldn't prove
it.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 23:38 ` Hyman Rosen
` (2 preceding siblings ...)
2004-02-04 7:00 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 10:28 ` Stuart Palin
2004-02-04 15:07 ` Hyman Rosen
3 siblings, 1 reply; 203+ messages in thread
From: Stuart Palin @ 2004-02-04 10:28 UTC (permalink / raw)
Hyman Rosen wrote:
> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.
I am no expert in these matters, but I thought that at some
time in the [distant] past the argument was made that the
ambiguity allows optimization: in particular optimization in
systems employing highly parallel computing architectures.
In such systems, different parts of an expression could be
'farmed out' and computed in parallel because there was no
assumption of any sequential order.
This argument should also have merit in cases where
processors have multiple execution units and support for
out-of-order execution. Just how far must a compiler go in
preserving the sequential order written in the source code?
I would agree with you that in most run-of-the-mill software
cases the lack of definite execution order does create a
pitfall for the unwary. But, it also creates an opportunity
for 'smart compilers' to optimize. In the end, surely, the
language must strike a balance in judging the true intent of
an author (when they are writing vanilla programs). Is the
serialization of an expression a specific requirement or an
unwanted by-product of the format of the source code!
On balance [however much I might find it a pain in my line
of programming], I think that the language has chosen the
most pragmatic approach. Those of us who are really
concerned about the matter will add it to our list of
concerns [and then probably turn to SPARK to save us from
ourselves :-) ]
--
Stuart Palin
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-04 10:28 ` Stuart Palin
@ 2004-02-04 15:07 ` Hyman Rosen
2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
2004-02-05 12:11 ` Stuart Palin
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 15:07 UTC (permalink / raw)
Stuart Palin wrote:
> But, it also creates an opportunity for 'smart compilers' to optimize.
Notice that if an expression has only one possible value regardless of
evaluation order then the compiler can evaluate it in any order it wants,
and with the current evaluation rules, it is unwise to write expressions
that have more than one possible value based on evaluation order. So no
correct existing programs necessarily need to be pessimized by fixing
evaluation order.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:07 ` Hyman Rosen
@ 2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
2004-02-04 15:54 ` Hyman Rosen
2004-02-05 12:11 ` Stuart Palin
1 sibling, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-04 15:19 UTC (permalink / raw)
Hyman Rosen wrote:
>it is unwise to write expressions that have more than one possible
>value based on evaluation order.
It is not only unwise, it is plain stupid.
>So no correct existing programs necessarily need to be pessimized by
>fixing evaluation order.
Precisely. You don't need to fix the evaluation order. It wouldn't
help anyway because the code remains to be stupid.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 15:54 ` Hyman Rosen
2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 15:54 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> It is not only unwise, it is plain stupid.
Under current rules.
> Precisely. You don't need to fix the evaluation order. It wouldn't
> help anyway because the code remains to be stupid.
It would help by making the "stupid" code work the same way
everywhere, cutting down an opportunity for error. And then
it would lead to non-stupid uses, such as the initialization
code I've been posting.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:54 ` Hyman Rosen
@ 2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
2004-02-04 17:13 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-04 16:36 UTC (permalink / raw)
Hyman Rosen wrote:
>It would help by making the "stupid" code work the same way
>everywhere, cutting down an opportunity for error. And then
>it would lead to non-stupid uses, such as the initialization
>code I've been posting.
Maybe. But it will also lead to more stupid code because we now know
about the evaluation order and thus can (or even: must) do
optimizations ourselves. That sort of optimizations that we would
normally leave to the compiler.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 16:36 ` Vinzent 'Gadget' Hoefler
@ 2004-02-04 17:13 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-04 17:13 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Maybe. But it will also lead to more stupid code because we now know
> about the evaluation order and thus can (or even: must) do
> optimizations ourselves. That sort of optimizations that we would
> normally leave to the compiler.
Do you have an example? What sort of optimization is implied by
order of evaluation that would lead a programmer to choose one
way over another?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-04 15:07 ` Hyman Rosen
2004-02-04 15:19 ` Vinzent 'Gadget' Hoefler
@ 2004-02-05 12:11 ` Stuart Palin
2004-02-05 13:22 ` Hyman Rosen
1 sibling, 1 reply; 203+ messages in thread
From: Stuart Palin @ 2004-02-05 12:11 UTC (permalink / raw)
Hyman Rosen wrote:
>
> Stuart Palin wrote:
> > But, it also creates an opportunity for 'smart compilers' to optimize.
>
> Notice that if an expression has only one possible value regardless of
> evaluation order then the compiler can evaluate it in any order it wants,
> and with the current evaluation rules, it is unwise to write expressions
> that have more than one possible value based on evaluation order. So no
> correct existing programs necessarily need to be pessimized by fixing
> evaluation order.
But the premise in many of your other postings in this
thread seems to be concerned with resolving the case where
the expression [currently] has an 'ambiguous' value.
As has already been pointed out in this thread, an Ada
compiler can not determine - simply from its specification -
whether a function will have a side-effect or not. (SPARK
resolves the issue by extending specifications with
annotations; but then it is striking a different balance
between flexibility in the design and verifiability of
behaviour).
I agree with you that it is unwise to write expressions that
[unintentionally] have more than one possible value; but I
think the point I made still stands. Ada seems to have (as
a matter of pragmatism) chosen not to prohibit certain
aspects of ambiguity because the potential benefits [in a
wide range of cases] out-weigh the pitfalls.
[Again, re-affirming my lack of expertise in these matters
of the Ada language, the 'pragmatic view' seems to be that:
a) people would mostly write functions without side-effects,
b) if they are writing functions with side-effects they
would/should be especially careful how they use them anyhow,
and c) Good performance in embedded real-time systems (on a
variety of targets) is desirable [essential if you consider
Ada to be targeted at the real-time embedded application
market]: consequently, in general the order of evaluation is
not fixed; allowing compilers to find an optimal
implementation order - including concurrent computation.
This may seem even more reasonable if one acknowledges there
are other cases where ambiguous behaviour can arise - for
instance data aliasing through parameter passing (another
thing prevented by SPARK) - so the die is cast!]
If your proposal to define the execution order were to be
adopted, how might a programmer write the Ada code to
express their intent that they don't care what order the
expression is executed in (provided it respected the
precedence rules) - they just want the most efficient
implementation?
How much do you think this [manual optimization] would add
to/detract from the clarity of the code?
How do you think someone who is writing applications for a
target that offers high levels of parallel computation would
feel about it?
--
Stuart Palin
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-05 12:11 ` Stuart Palin
@ 2004-02-05 13:22 ` Hyman Rosen
2004-02-05 14:53 ` Robert I. Eachus
2004-02-06 10:27 ` Stuart Palin
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-05 13:22 UTC (permalink / raw)
Stuart Palin wrote:
> But the premise in many of your other postings in this
> thread seems to be concerned with resolving the case where
> the expression [currently] has an 'ambiguous' value.
Yes.
> As has already been pointed out in this thread, an Ada
> compiler can not determine - simply from its specification -
> whether a function will have a side-effect or not.
Yes.
> Ada seems to have (as
> a matter of pragmatism) chosen not to prohibit certain
> aspects of ambiguity because the potential benefits [in a
> wide range of cases] out-weigh the pitfalls.
Those benefits being?
> allowing compilers to find an optimal implementation order
But you are now talking about finding an optimal implementation
order for an expression involving more than one function call
where the compiler has no access to the body of the functions.
Do you really think that allowing the compiler to pick the order
of the calls will significantly affect the efficiency?
> - including concurrent computation.
I don't see how this can possibly be allowed, unless the compiler
can see the bodies to inline them. The standard allows operands
and arguments to be evaluated in arbitrary order, but concurrent
execution would completely break any functions that accessed common
data structures.
> This may seem even more reasonable if one acknowledges there
> are other cases where ambiguous behaviour can arise - for
> instance data aliasing through parameter passing
Eliminating sources of ambiguity is a good thing even if not all
of them can be removed.
> If your proposal to define the execution order were to be
> adopted, how might a programmer write the Ada code to
> express their intent that they don't care what order the
> expression is executed in
They could not, just as they cannot specify this for sequences
of statements. If you write
x := a + b;
y := c + d;
you may not care which statement is executed first, but you have no
way of telling this to the compiler. Either the compiler can figure
this out for itself, or it can't.
> How much do you think this [manual optimization] would add
> to/detract from the clarity of the code?
I think this is non-existent now, and will continue to be so.
> How do you think someone who is writing applications for a
> target that offers high levels of parallel computation would
> feel about it?
They would feel that order of evaluation is completely orthogonal
to their concerns.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-05 13:22 ` Hyman Rosen
@ 2004-02-05 14:53 ` Robert I. Eachus
2004-02-05 15:43 ` Hyman Rosen
2004-02-06 10:27 ` Stuart Palin
1 sibling, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-05 14:53 UTC (permalink / raw)
Hyman Rosen wrote:
> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?
Of course it will. Consider for one example a Pure subprogram, say a
call to Sin or Log from a math package inside a loop. The pragma Pure
rules allow the compiler to hoist the call outside the loop, if the
parameter(s) are unchanged in successive calls.
YOU may think that is a contrived example, but it is not. That sort of
thing happens all the time in embedded flight dynamics systems where a
set of expressions is iterated a couple of times for convergence. And
even if the expressions are not iterated, they often include common
subexpressions that can be pulled out of line by the compiler. Any call
to a Pure function can be treated as a common subexpression, even if the
subprogram itself is not inlined.
This is one of the nice features of Ada for safety-critical systems.
The formulas for things like flight dynamics can be almost copied
verbatum from the specification, and the compiler (and Verifier!) can do
the grody work of finding an efficient implementation and showing that
it is equivalent.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-05 14:53 ` Robert I. Eachus
@ 2004-02-05 15:43 ` Hyman Rosen
2004-02-06 7:41 ` Robert I. Eachus
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-05 15:43 UTC (permalink / raw)
Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> But you are now talking about finding an optimal implementation
>> order for an expression involving more than one function call
>> where the compiler has no access to the body of the functions.
>> Do you really think that allowing the compiler to pick the order
>> of the calls will significantly affect the efficiency?
>
> Of course it will. Consider for one example a Pure subprogram, say a
> call to Sin or Log from a math package inside a loop. The pragma Pure
> rules allow the compiler to hoist the call outside the loop, if the
> parameter(s) are unchanged in successive calls.
Sigh. When I said "access to the body" I meant that the compiler has
no more information about what the function does than its declaration.
Obviously if a function is declared Pure then its return value is not
affected by order of execution, and the compiler can hoist away.
Think about it - if you write
s := Sin(x) + Cos(y)
Ada requires that both arguments are evaluated, but doesn't specify the
order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
each time in a loop, but can hoist the calculations out, as you say. Why
would specifying the order change this?
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-05 15:43 ` Hyman Rosen
@ 2004-02-06 7:41 ` Robert I. Eachus
2004-02-24 1:27 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-06 7:41 UTC (permalink / raw)
Hyman Rosen wrote:
> Think about it - if you write
> s := Sin(x) + Cos(y)
> Ada requires that both arguments are evaluated, but doesn't specify the
> order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
> each time in a loop, but can hoist the calculations out, as you say. Why
> would specifying the order change this?
That may be why you keep butting your head against a brick wall. If Ada
said that in an equation like: s := Sin(1-x) + Cos(y); that the terms
had to be evaluated left to right, that would say you couldn't evaluate
Cos(y) before Sin(1-x) whether or not they were declared Pure.
Ada does allow compilers to combine calls to Pure functions, and if that
is not okay, don't declare them Pure. But that doesn't say that Pure
functions can't have side effects. It just changes what a compiler is
allowed to do with Pure functions. In fact, right now on the ARG list
we are discussing a fix to 10.2.1 Elaboration Control which defines
pragma Pure and pragma Preelaborate. There are some new features in Ada
0Y that require some wording changes, and we want them to be as
restrictive as necessary, but no stricter. In that discussion we have
discussed exactly this issue. (A Pure subprogram call can be
eliminated, and if the subprogam has side-effects, well the programmer
was warned. No different from some other effects of optimizing compilers.
But note that what users have been warned about is that marking a unit
as Pure may allow the optimizer to eliminate some calls. The compilers
are not allowed to call the function somewhere that it wouldn't be
called otherwise. The compiler must insure that a Pure function that
would never be called in the canonical order is never called in the
order the compiler selects. And if two Pure functions have side
effects, and both are called, the side effects must happen in the right
order.
So the new rule that you are proposing would severly limit some very
useful optimizations, unless you had exceptions for Pure functions, and
predefined operators, and static expressions, and... Well you get the
picture. Soon you have more exceptions than case that are constrained
by the rule, and all to insure that functions with side-effects are
called in a single canonical order.
We prefer to have one easily understood set of rules. Unfortunately in
some useful cases these rules work out to "if you really want to be
sure, install a block with an exception handler." But this is based on
twenty years of experience. Users at all levels don't want strict
execution orders in most cases, but they all seem to want very good
optimization.
Also note incidently that what some users really do care about, and
which has raised entirely too much discussion for something that will
never be changed, is short-circut expression evaluation. I don't know
how many requests I have seen in various forms for redefining 'or' to
mean 'or else' and 'and' to mean 'and then'. (The proposals for the
current meanings of 'and' and 'or' have lots of different syntax
suggestions associated with them.) But the real unalterable answer is
NO! (Or maybe something more forceful.) There is too much existing code
that depends on the current rules and the cost of revising that code is
totally out of proportion to the potential savings--which I don't even
think exist. The compiler can use short circut forms if the expression
after 'and' or 'if' is marked Pure or a static expression, or only
involves predefined expressions, etc. (See the similar list above,
which is what brought it to mind. ;-)
So the only cases where the proposed rule change would make a difference
are exactly those cases that would have to be revised in existing code.
And when you check on why the request was made, it often resulted from
an error message at compile time. The message can always be eliminated
by changing the 'and' to 'and then' or the 'or' to 'or else'. But in
practice the programmer really has to think to be sure that is the right
change.
It is the required thinking that seems to generate the revision
requests. If 'and then' and 'or else' were the defaults then they
wouldn't need to think during compilation, and they could wait for an
exception at run-time. ;-)
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-06 7:41 ` Robert I. Eachus
@ 2004-02-24 1:27 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-24 1:27 UTC (permalink / raw)
Robert I. Eachus wrote:
> That may be why you keep butting your head against a brick wall. If Ada
> said that in an equation like: s := Sin(1-x) + Cos(y); that the terms
> had to be evaluated left to right, that would say you couldn't evaluate
> Cos(y) before Sin(1-x) whether or not they were declared Pure.
>
> Ada does allow compilers to combine calls to Pure functions, and if that
> is not okay, don't declare them Pure. But that doesn't say that Pure
> functions can't have side effects. It just changes what a compiler is
> allowed to do with Pure functions.
I am not butting my head against a brick wall, I am butting into brick heads.
(Who was it who defined teaching as the art of pounding abstract facts into
concrete heads? :-)
Right now, the ARM says that the operands in an expression are evaluated in
arbitrary order, and I would propose that it say that operands are evaluated
left-to-right. Neither of those statements gives any permission to not call
a subprogram present in an expression.
The section that specifies pragma Pure says that under certain circumstances,
a call to a pure function may be omitted and replaced with the results of a
previous call. That would remain as true in the left-to-right version as in
the arbitrary order version. The concepts are entirely orthogonal.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-05 13:22 ` Hyman Rosen
2004-02-05 14:53 ` Robert I. Eachus
@ 2004-02-06 10:27 ` Stuart Palin
2004-02-24 1:55 ` Hyman Rosen
1 sibling, 1 reply; 203+ messages in thread
From: Stuart Palin @ 2004-02-06 10:27 UTC (permalink / raw)
Hyman Rosen wrote:
> > Ada seems to have (as
> > a matter of pragmatism) chosen not to prohibit certain
> > aspects of ambiguity because the potential benefits [in a
> > wide range of cases] out-weigh the pitfalls.
>
> Those benefits being?
>
> > allowing compilers to find an optimal implementation order
... allowing compilers to find an optimal implementation
order!???
> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?
>
> > - including concurrent computation.
Yes - as Robert Eachus has illustrated much better than I
could.
> Eliminating sources of ambiguity is a good thing even if not all
> of them can be removed.
Agreed, but to emphasize the point made by Robert Eachus -
if the rules you introduce are too complex the cure is worse
than the disease. There is some merit in having a set of
rules that are perhaps imperfect, but are simpler to
understand: at least you are sure of where you stand.
> > If your proposal to define the execution order were to be
> > adopted, how might a programmer write the Ada code to
> > express their intent that they don't care what order the
> > expression is executed in
>
> They could not, just as they cannot specify this for sequences
> of statements. If you write
> x := a + b;
> y := c + d;
> you may not care which statement is executed first, but you have no
> way of telling this to the compiler. Either the compiler can figure
> this out for itself, or it can't.
or you could possibly identify that x and y are part of a
common object and so might be processed jointly:
type doublet is record
x : ... ;
y : ... ;
end record;
...
XY : doublet;
...
XY := doublet'(x => a+b, y => c+d);
If they are truly unconnected objects then perhaps they
should be processed in separate tasks.
However, I think that in practice the language has taken a
pragmatic view of where to draw the line in balancing
'ambiguity' of order with optimization: within a single
expression the order of evaluation may be ambiguous, between
separate statements it may not.
--
Stuart Palin
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-06 10:27 ` Stuart Palin
@ 2004-02-24 1:55 ` Hyman Rosen
2004-02-24 2:16 ` David Starner
2004-02-24 8:22 ` Jacob Sparre Andersen
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-24 1:55 UTC (permalink / raw)
Stuart Palin wrote:
> ... allowing compilers to find an optimal implementation order!???
But as you go on to quote me, the cases where the compiler would not
be permitted to do this are relatively rare, and involve the presence
of multiple function calls within an expression. In such a case, how
much optimization will operand reordering buy?
>>>- including concurrent computation.
Where does Ada permit the concurrent execution of multiple function
calls of an expression?
> if the rules you introduce are too complex the cure is worse
> than the disease.
Fortunately, the rules I introduce are not.
> There is some merit in having a set of rules that are perhaps
> imperfect, but are simpler to understand: at least you are sure
> of where you stand.
Yes, that's what my rules would accomplish. There are many people
who are astonished to realize that in
a := f(a(0)) + g(b(1));
the only constraints are that a is called before f and b before g,
but nothing else is required, so that six orders are possible:
abfg abgf afbg bafg bagf bgaf
> XY := doublet'(x => a+b, y => c+d);
>
> If they are truly unconnected objects then perhaps they
> should be processed in separate tasks.
I will leave it to the people who describe Ada code as readeable to
tell me whether turning a sequence of assignments into an aggregate
or a pair of tasks is a good idea.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-24 1:55 ` Hyman Rosen
@ 2004-02-24 2:16 ` David Starner
2004-02-24 14:51 ` Hyman Rosen
2004-02-24 8:22 ` Jacob Sparre Andersen
1 sibling, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-24 2:16 UTC (permalink / raw)
On Tue, 24 Feb 2004 01:55:41 +0000, Hyman Rosen wrote:
> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
> a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
> abfg abgf afbg bafg bagf bgaf
And there are many people who would be astonished if it matters
and feel compelled to go find the author and beat them over the
head with the ARM.
In any case, there are a lot of things many people would be
astonished to realize. Many people were astonished to realize
that C ints weren't 16 bits long; that didn't mean that the
standard should have changed the definition. Many people
are also astonished to find out that the size of an integer
isn't necessarily the same size as a pointer.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-24 2:16 ` David Starner
@ 2004-02-24 14:51 ` Hyman Rosen
2004-02-24 23:55 ` David Starner
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-24 14:51 UTC (permalink / raw)
David Starner wrote:
> And there are many people who would be astonished if it matters
> and feel compelled to go find the author and beat them over the
> head with the ARM.
As I have said over and over again, the problematic case is when
it matters, and no one notices, and the compiler happens to do
what you want. Then a change in environment could result in the
order changing, and all of a sudden, code mysteriously breaks.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-24 14:51 ` Hyman Rosen
@ 2004-02-24 23:55 ` David Starner
2004-02-25 0:44 ` Stephen Leake
0 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-24 23:55 UTC (permalink / raw)
On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> As I have said over and over again, the problematic case is when
> it matters, and no one notices, and the compiler happens to do
> what you want. Then a change in environment could result in the
> order changing, and all of a sudden, code mysteriously breaks.
And the life and death case is when it matters and the compiler does
what you want, and then maintainers change something, and after they
discover there were uncommented, incredibly subtle order issues, they
go out to kill the original smart-ass programmer.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-24 23:55 ` David Starner
@ 2004-02-25 0:44 ` Stephen Leake
2004-02-25 9:21 ` Dmitry A. Kazakov
` (4 more replies)
0 siblings, 5 replies; 203+ messages in thread
From: Stephen Leake @ 2004-02-25 0:44 UTC (permalink / raw)
To: comp.lang.ada
David Starner <dvdeug@email.ro> writes:
> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> > As I have said over and over again, the problematic case is when
> > it matters, and no one notices, and the compiler happens to do
> > what you want. Then a change in environment could result in the
> > order changing, and all of a sudden, code mysteriously breaks.
>
> And the life and death case is when it matters and the compiler does
> what you want, and then maintainers change something, and after they
> discover there were uncommented, incredibly subtle order issues, they
> go out to kill the original smart-ass programmer.
I think Hyman has two valid points:
1) if the language specified left-to-right order, there would never be
a need to "kill the original smart-ass programmer"
2) Does anyone have a real example of a compiler taking advantage of
the evaluation order freedom to speed up a program?
Ada is supposed to be about clear, unsurprising code. Subtle order
issues are just that - "subtle". If the language _could_ make them a
non-issue, at very little cost, I think it _should_.
I have not heard anyone respond to 2), which is supposedly the reason
the freedom is there. If no compiler actually takes advantage of it,
it's not worth having.
I don't think there's much chance Ada will change in this area; it
would cost more to change the documentation than it is worth.
But we can at least be honest about it!
--
-- Stephe
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 0:44 ` Stephen Leake
@ 2004-02-25 9:21 ` Dmitry A. Kazakov
2004-02-25 9:33 ` David Starner
` (3 subsequent siblings)
4 siblings, 0 replies; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-25 9:21 UTC (permalink / raw)
On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
wrote:
>David Starner <dvdeug@email.ro> writes:
>
>> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
>> > As I have said over and over again, the problematic case is when
>> > it matters, and no one notices, and the compiler happens to do
>> > what you want. Then a change in environment could result in the
>> > order changing, and all of a sudden, code mysteriously breaks.
>>
>> And the life and death case is when it matters and the compiler does
>> what you want, and then maintainers change something, and after they
>> discover there were uncommented, incredibly subtle order issues, they
>> go out to kill the original smart-ass programmer.
>
>I think Hyman has two valid points:
>
>1) if the language specified left-to-right order, there would never be
> a need to "kill the original smart-ass programmer"
But also, if the language disallowed side-effects when there could be
more than one order. I prefer the second, provided that the term
"side-effect" should be formally defined by the language and visible
from the specifications.
>2) Does anyone have a real example of a compiler taking advantage of
> the evaluation order freedom to speed up a program?
The question is what gets lost if an evaluation order is fixed. I gave
an example earlier:
for I in A'Range loop
Sum := Sum + A (I) + B (B'First + I - A'First);
...
Here with left-to-right order the compiler cannot optimize neither the
array index of B, nor can it increment Sum by adding A()+B(). Well,
these optimizations could be made possible if the compiler might prove
that the result does not depend on the order. That could be quite
difficult to formally define, especially regarding numeric exceptions
and floating-point accuracy stuff. Even more difficult it would be
check.
But finally, if all that could be achived, then the compiler will be
capable to simply detect that different orders give different results,
and threat it as an error. Much better than fixing an arbitrary order!
So the bottom line, IMO, 1 makes no sense.
>Ada is supposed to be about clear, unsurprising code. Subtle order
>issues are just that - "subtle". If the language _could_ make them a
>non-issue, at very little cost, I think it _should_.
Right, the present situation is not good. But IMO the solution lies in
introducing formally pure functions and imposing limitations on use of
impure functions (and procedures with results) in expressions.
>I have not heard anyone respond to 2), which is supposedly the reason
>the freedom is there. If no compiler actually takes advantage of it,
>it's not worth having.
>
>I don't think there's much chance Ada will change in this area; it
>would cost more to change the documentation than it is worth.
>
>But we can at least be honest about it!
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 0:44 ` Stephen Leake
2004-02-25 9:21 ` Dmitry A. Kazakov
@ 2004-02-25 9:33 ` David Starner
2004-02-25 14:21 ` Hyman Rosen
2004-02-25 12:01 ` Marin David Condic
` (2 subsequent siblings)
4 siblings, 1 reply; 203+ messages in thread
From: David Starner @ 2004-02-25 9:33 UTC (permalink / raw)
On Tue, 24 Feb 2004 19:44:12 -0500, Stephen Leake wrote:
> 1) if the language specified left-to-right order, there would never be
> a need to "kill the original smart-ass programmer"
If it got changed in maintenance, and introduced a bug because no one
saw the hidden dependency, then there would be.
> Ada is supposed to be about clear, unsurprising code. Subtle order
> issues are just that - "subtle". If the language _could_ make them a
> non-issue, at very little cost, I think it _should_.
But it doesn't change the meaning of much clear, unsurprising code. Most
of the examples depend on hidden state. The rest depend on I/O. Neither
occur much in clear, unsurprising code.
(Okay, so I/O is necessary in programs. But the examples using I/O
can be rewritten not to use this, and are usually pretty obvious.)
> I don't think there's much chance Ada will change in this area; it
> would cost more to change the documentation than it is worth.
>
> But we can at least be honest about it!
I think part of it is language philosophy. Ada is not C, but it's not
Java, either. Ada's goal is not to make every program run exactly the same
everywhere. Perhaps the supposed efficiency goals aren't achieved by this
choice, but reversing the choice, and helping some marginal code become
legal, isn't a huge win in the terms of Ada's choices.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 9:33 ` David Starner
@ 2004-02-25 14:21 ` Hyman Rosen
2004-02-25 14:34 ` Vinzent 'Gadget' Hoefler
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 14:21 UTC (permalink / raw)
David Starner wrote:
> I think part of it is language philosophy.
What philosophy requires the retention of a feature
that offers no benefits and can be removed without
affecting legal programs?
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 14:21 ` Hyman Rosen
@ 2004-02-25 14:34 ` Vinzent 'Gadget' Hoefler
2004-02-25 15:02 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-25 14:34 UTC (permalink / raw)
Hyman Rosen wrote:
>David Starner wrote:
>> I think part of it is language philosophy.
>
>What philosophy requires the retention of a feature
>that offers no benefits and can be removed without
>affecting legal programs?
The philosophy that the semantics of a program should be the same, no
matter if you choose to write "f := a + b;" or "f = b + a;" instead.
With that in mind, it is easier to make someone aware of better
writing functions *without* side-effects, which is supposed to be a
good thing. :-)
BTW, AFAICS and JFTR: C and C++ don't specify evaluation either (I
don't know if Java does fix it), except when sequence points are
involved. The only difference is that unfortunately all Boolean
operations happen to be sequence points here.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 14:34 ` Vinzent 'Gadget' Hoefler
@ 2004-02-25 15:02 ` Hyman Rosen
2004-02-25 15:43 ` Vinzent 'Gadget' Hoefler
` (2 more replies)
0 siblings, 3 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 15:02 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> The philosophy that the semantics of a program should be the same, no
> matter if you choose to write "f := a + b;" or "f = b + a;" instead.
But Ada does not have that philosophy, so that cannot be the reason
to maintain the feature. When "+" is a user-defined subprogram, its
operands are always passed in the order written; a + b is always
invoked as "+"(a, b) and never as "+"(b, a).
> BTW, AFAICS and JFTR: C and C++ don't specify evaluation either
Correct. I've made the same arguments in the C++ newsgroups :-)
> (I don't know if Java does fix it)
It does.
> The only difference is that unfortunately all Boolean
> operations happen to be sequence points here.
"Unfortunately"? Built-in && is the equivalent of Ada "and then"
and || is the equivalent of "or else". What exactly makes that
unfortunate?
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 15:02 ` Hyman Rosen
@ 2004-02-25 15:43 ` Vinzent 'Gadget' Hoefler
2004-02-25 15:53 ` Hyman Rosen
2004-02-25 15:44 ` Hyman Rosen
2004-02-25 16:10 ` Robert I. Eachus
2 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-25 15:43 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> The philosophy that the semantics of a program should be the same, no
>> matter if you choose to write "f := a + b;" or "f = b + a;" instead.
>
>But Ada does not have that philosophy, so that cannot be the reason
>to maintain the feature.
It has it for built-in functions where the compiler knows that it
doesn't make any difference.
>When "+" is a user-defined subprogram, its
>operands are always passed in the order written; a + b is always
>invoked as "+"(a, b) and never as "+"(b, a).
Well, yes.
Think of the case where "+" might not be commutative. I guess it would
be too much burden to specify in the standard that the compiler should
be able to figure out if this is the case or not in each particular
case. The simplest example would be a "+" where a and b have different
types. ;-)
>> The only difference is that unfortunately all Boolean
>> operations happen to be sequence points here.
>
>"Unfortunately"? Built-in && is the equivalent of Ada "and then"
>and || is the equivalent of "or else". What exactly makes that
>unfortunate?
There's no equivalent of an Ada's "and" and "or" where the compiler
can evaluate if the comparison with the result of a costly square-root
function should be delayed until we can figure out if the simple
boolean flag already gives us the result:
|if (Sqrt (x) > 5.0) and b then ...
So you should always write this in the most efficient order then, even
if it might not be the most intuitive way.
BTW, the above is another reason why you shouldn't write functions
with side effects, because if you do the compiler *has* to evaluate
Sqrt, too. :-)
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 15:43 ` Vinzent 'Gadget' Hoefler
@ 2004-02-25 15:53 ` Hyman Rosen
2004-02-25 16:05 ` Vinzent 'Gadget' Hoefler
` (2 more replies)
0 siblings, 3 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 15:53 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Think of the case where "+" might not be commutative.
Exactly. So as I said, Ada has no philosophy that a + b
means the same thing as b + a. Thus it is not a relevant
argument against specifying order of evaluation.
> There's no equivalent of an Ada's "and" and "or" where the compiler
> can evaluate if the comparison with the result of a costly square-root
> function should be delayed until we can figure out if the simple
> boolean flag already gives us the result:
>
> |if (Sqrt (x) > 5.0) and b then ...
How would knowing that b is false help the compiler not call the
costly operation? The rules of Ada require that for "and", both
operands are evaluated! If you are really intent on writing such
code in C or C++, you may say !!a & !!b, where the hideousness
will give a clue to the reader that something weird is going on.
> BTW, the above is another reason why you shouldn't write functions
> with side effects, because if you do the compiler *has* to evaluate
> Sqrt, too. :-)
If the compiler knows enough about Sqrt to know that it has no side
effects, then it will have no problem checking b first even if you
write (sqrt(x) > 5.0 and then b).
Really, all these arguments sound so desperate.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 15:53 ` Hyman Rosen
@ 2004-02-25 16:05 ` Vinzent 'Gadget' Hoefler
2004-02-25 16:44 ` Hyman Rosen
2004-02-25 16:34 ` Preben Randhol
2004-02-25 16:35 ` Preben Randhol
2 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-25 16:05 UTC (permalink / raw)
Hyman Rosen wrote:
>The rules of Ada require that for "and", both
>operands are evaluated!
No, it doesn't.
>> BTW, the above is another reason why you shouldn't write functions
>> with side effects, because if you do the compiler *has* to evaluate
>> Sqrt, too. :-)
>
>If the compiler knows enough about Sqrt to know that it has no side
>effects, then it will have no problem checking b first even if you
>write (sqrt(x) > 5.0 and then b).
Well, in *this* case you *want* it to be evaluated first, I guess. :)
>Really, all these arguments sound so desperate.
Well, I don't build compilers. But - AFAICS - the only reason for not
fixing the evaluation order usually *is* code optimization.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:05 ` Vinzent 'Gadget' Hoefler
@ 2004-02-25 16:44 ` Hyman Rosen
2004-02-25 20:45 ` Randy Brukardt
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 16:44 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>The rules of Ada require that for "and", both
>>operands are evaluated!
> No, it doesn't.
ARM 4.5/11 says
"The two operands of an expression of the form X op Y,
where op is a binary operator, are evaluated in an
arbitrary order, as for any function_call (see 6.4)."
Where do you find permission for Ada to not evaluate one
operand of an "and" or "or" expression?
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 16:44 ` Hyman Rosen
@ 2004-02-25 20:45 ` Randy Brukardt
2004-02-25 21:33 ` Hyman Rosen
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
1 sibling, 1 reply; 203+ messages in thread
From: Randy Brukardt @ 2004-02-25 20:45 UTC (permalink / raw)
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1077727496.631820@master.nyc.kbcfp.com...
> ARM 4.5/11 says
> "The two operands of an expression of the form X op Y,
> where op is a binary operator, are evaluated in an
> arbitrary order, as for any function_call (see 6.4)."
>
> Where do you find permission for Ada to not evaluate one
> operand of an "and" or "or" expression?
11.6(5), of course. Since there is no requirement to evaluate a function
solely to see if it raises an exception (since the result is not needed in
this case), the entire call can be removed.
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 20:45 ` Randy Brukardt
@ 2004-02-25 21:33 ` Hyman Rosen
2004-02-26 8:45 ` Preben Randhol
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 21:33 UTC (permalink / raw)
Randy Brukardt wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
>
> 11.6(5), of course.
For the particular case of sqrt(x), where we're talking
about Ada's built-in sqrt, and the only possible side-effect
is for it to raise an exception. But if instead we have
(gnurble(x) > 0.5 and b), and the compiler knows that b is
false but has no information about what gnurble does, it
must call gnurble(x) even though the result is irrelevant.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 21:33 ` Hyman Rosen
@ 2004-02-26 8:45 ` Preben Randhol
2004-02-26 8:46 ` Preben Randhol
2004-02-26 14:41 ` Hyman Rosen
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
1 sibling, 2 replies; 203+ messages in thread
From: Preben Randhol @ 2004-02-26 8:45 UTC (permalink / raw)
On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Randy Brukardt wrote:
>> "Hyman Rosen" <hyrosen@mail.com> wrote
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>>
>> 11.6(5), of course.
>
> For the particular case of sqrt(x), where we're talking
> about Ada's built-in sqrt, and the only possible side-effect
> is for it to raise an exception. But if instead we have
> (gnurble(x) > 0.5 and b), and the compiler knows that b is
> false but has no information about what gnurble does, it
> must call gnurble(x) even though the result is irrelevant.
Or you have to do:
value := gnuble(x);
if value > 0.5 and b then
to be sure that any side effects are performed.
with Ada.Text_IO; use Ada.Text_IO;
procedure eval is
flag : Boolean := false;
function gnurble(value : Float) return Float is
begin
Put_Line ("I was called");
return value + 99.0;
end gnurble;
begin
if flag and gnurble (1.0) > 2.0 then
-- if gnurble (1.0) > 2.0 and flag then -- or this case
-- if false and gnurble (1.0) > 2.0 then -- or this
-- if gnurble (1.0) > 2.0 and false then -- or this
Put_Line ("True");
else
Put_Line ("False");
end if;
end eval;
For all these cases I get that the gnurble function was called and the
if statment is of course false. Even with optimisation.
However if you do this:
with Ada.Text_IO; use Ada.Text_IO;
procedure eval is
flag : Boolean := false;
function gnurble(value : Float) return Float is
begin
flag := true; -- Added a side effect
Put_Line ("I was called");
return value + 99.0;
end gnurble;
begin
if flag and gnurble (1.0) > 2.0 then -- Case 1
-- if gnurble (1.0) > 2.0 and flag then -- Case 2
Put_Line ("True");
else
Put_Line ("False");
end if;
end eval;
The result is:
Case 1:
% ./eval
I was called
True
Case 2:
% ./eval
I was called
True
Wheras if you do:
if flag and then gnurble (1.0) > 2.0 then
then gnurble is never called of course.
Compiler GNAT 3.15p
--
"Saving keystrokes is the job of the text editor, not the programming
language."
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 8:45 ` Preben Randhol
@ 2004-02-26 8:46 ` Preben Randhol
2004-02-26 14:41 ` Hyman Rosen
1 sibling, 0 replies; 203+ messages in thread
From: Preben Randhol @ 2004-02-26 8:46 UTC (permalink / raw)
On 2004-02-26, Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.
Note when I say optimisation I only did: gnatmake -O3
I didn't have time to check the UG for other optimisation flags...
--
"Saving keystrokes is the job of the text editor, not the programming
language."
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 8:45 ` Preben Randhol
2004-02-26 8:46 ` Preben Randhol
@ 2004-02-26 14:41 ` Hyman Rosen
1 sibling, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 14:41 UTC (permalink / raw)
Preben Randhol wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.
We're in violent agreement here. Everything you report is
exactly how I exepcted it to be. (Except for the case of
the gnurble which modifies the flag, where I don't have any
expectations.)
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 21:33 ` Hyman Rosen
2004-02-26 8:45 ` Preben Randhol
@ 2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
2004-02-26 13:24 ` Robert I. Eachus
1 sibling, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-26 9:44 UTC (permalink / raw)
Hyman Rosen wrote:
>For the particular case of sqrt(x), where we're talking
>about Ada's built-in sqrt, and the only possible side-effect
>is for it to raise an exception. But if instead we have
>(gnurble(x) > 0.5 and b), and the compiler knows that b is
>false but has no information about what gnurble does, it
>must call gnurble(x) even though the result is irrelevant.
Yes, it should (I'm not sure, if it actually *has to*) call the
function if it is possible that the function has side-effects.
What's your problem here?
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
@ 2004-02-26 13:24 ` Robert I. Eachus
2004-02-26 14:33 ` Jean-Pierre Rosen
` (2 more replies)
0 siblings, 3 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-26 13:24 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>
>> For the particular case of sqrt(x), where we're talking about Ada's
>> built-in sqrt, and the only possible side-effect is for it to raise
>> an exception. But if instead we have (gnurble(x) > 0.5 and b), and
>> the compiler knows that b is false but has no information about
>> what gnurble does, it must call gnurble(x) even though the result
>> is irrelevant.
>
>
> Yes, it should (I'm not sure, if it actually *has to*) call the
> function if it is possible that the function has side-effects.
>
> What's your problem here?
>
That he has never read 10.2.1(18)? "If a library unit is declared pure,
then the implementation is permitted to omit a call on a library-level
subprogram of the library unit if the results are not needed after the
call. Similarly, it may omit such a call and simply reuse the results
produced by an earlier call on the same subprogram, provided that none
of the parameters are of a limited type, and the addresses and values of
all by-reference actual parameters, and the values of all by-copy-in
actual parameters, are the same as they were at the earlier call. This
permission applies even if the subprogram produces other side effects
when called."
Can't we just all agree that Hymen is not an Ada language expert and
doesn't want to be? In this case, the rules of Ada are well thought out
to allow any user, not the compiler to determine whether an
"unnecessary" function call can be eliminated. Similarly, the language
allows users to force syncronization points and orders of evaluation,
when they are a necessary part of the algorithm being implemented.
We have jokingly called for shooting a programmer who knowingly writes
code that depends on order of evaluation and then--yes that is an Ada
and then--doesn't document it or force the compiler to use the necessary
order. Actually the correction applied would probably be education,
warnings, bad reviews, and eventually firing the employee if nececssary.
For anyone who deliberately persists in such bad habits, if necessary
could be within weeks. Emphasis on deliberately, but I have had to make
that decision for programmers who persisted in other bad habits like
bypassing the required check-in procedures for software. In that case,
firing the programmer probably saved him from a lynch mob, as other
programmmers kept finding their submissions being rejected due to his
changes not passing the regression tests.
What do we do with Mr. Hymen Rosen? For now, I'm going to just post
chapter and verse, and that Mr. Rosen's opinion on any Ada language
issue should be ignored.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 13:24 ` Robert I. Eachus
@ 2004-02-26 14:33 ` Jean-Pierre Rosen
2004-02-28 17:11 ` Robert I. Eachus
2004-02-26 15:21 ` Hyman Rosen
2004-02-27 5:21 ` Stephen Leake
2 siblings, 1 reply; 203+ messages in thread
From: Jean-Pierre Rosen @ 2004-02-26 14:33 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
"Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
> What do we do with Mr. Hymen Rosen? For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.
>
Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
people :-)
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 14:33 ` Jean-Pierre Rosen
@ 2004-02-28 17:11 ` Robert I. Eachus
0 siblings, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-28 17:11 UTC (permalink / raw)
Jean-Pierre Rosen wrote:
> "Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
>
>>What do we do with Mr. Hymen Rosen? For now, I'm going to just post
>>chapter and verse, and that Mr. Rosen's opinion on any Ada language
>>issue should be ignored.
> Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
> people :-)
Good point, I explicitly qualified the first reference for just that
reason--that the paragraph might be quoted out of context. I probably
should have either used "his" or a full name for the second reference as
well.
As you well know, of course, it is very hard to write something that
doesn't sound stilted, and still stands up to hostile (mis-)interpretation.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 13:24 ` Robert I. Eachus
2004-02-26 14:33 ` Jean-Pierre Rosen
@ 2004-02-26 15:21 ` Hyman Rosen
2004-02-27 5:21 ` Stephen Leake
2 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 15:21 UTC (permalink / raw)
Robert I. Eachus wrote:
> Vinzent 'Gadget' Hoefler wrote:
>> What's your problem here?
> That he has never read 10.2.1(18)?
> Can't we just all agree that Hyman is not an Ada language expert and
> doesn't want to be? ... What do we do with Mr. Hyman Rosen? For now,
> I'm going to just post chapter and verse, and that Mr. Rosen's opinion
> on any Ada language issue should be ignored.
This particular subthread started when V'G'H stated that in C/C++
"The only difference is that unfortunately all Boolean
operations happen to be sequence points here."
When I asked him why this was unfortunate, he replied that the Ada
if (Sqrt (x) > 5.0) and b then
permitted Ada to test b first, and not call Sqrt(x) if b was false.
I pointed out that unless sqrt(x) (later amended to gnurble(x)) was
known to the compiler to be free of side-effects, the compiler must
call it regardless of the value of b. I also pointed out that under
similar circumstances
if (Sqrt (x) > 5.0) and then b then
would allow exactly the same optimization to be performed, i.e., b
could be tested first and sqrt(x) need not be called if b is false.
I assume 10.2.1(18)'s "results are not needed" allows the compiler
to be as brilliant as it wants to be in determining this?
In these discussions I tend to use the phrase "free of side-effects"
as shorthand. I know that prgama pure subprograms are permitted to
have side-effects, but that's not germane to the discussion, and I
don't feel like adding "or pure" all over the place.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 13:24 ` Robert I. Eachus
2004-02-26 14:33 ` Jean-Pierre Rosen
2004-02-26 15:21 ` Hyman Rosen
@ 2004-02-27 5:21 ` Stephen Leake
2004-02-27 8:55 ` David Starner
2 siblings, 1 reply; 203+ messages in thread
From: Stephen Leake @ 2004-02-27 5:21 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net> writes:
> <snip 10.2.1 (18)>
>
> Can't we just all agree that Hymen is not an Ada language expert and
> doesn't want to be?
I don't think that is a fair characterization of Hymen's discussions.
> In this case, the rules of Ada are well thought out to allow any
> user, not the compiler to determine whether an "unnecessary"
> function call can be eliminated. Similarly, the language allows
> users to force syncronization points and orders of evaluation, when
> they are a necessary part of the algorithm being implemented.
Hymen is asking about the value of these rules _in practice_, and
attempting to discuss whether a slightly different set of rules might
be better for Ada.
In particular, are there any _actual compilers_ that take advantage of
the freedom given by 10.2.1 (18)?
> We have jokingly called for shooting a programmer who knowingly
> writes code that depends on order of evaluation and then--yes that
> is an Ada and then--doesn't document it or force the compiler to use
> the necessary order. Actually the correction applied would probably
> be education, warnings, bad reviews, and eventually firing the
> employee if nececssary.
>
> For anyone who deliberately persists in such bad habits, if necessary
> could be within weeks. Emphasis on deliberately, but I have had to
> make that decision for programmers who persisted in other bad habits
> like bypassing the required check-in procedures for software. In that
> case, firing the programmer probably saved him from a lynch mob, as
> other programmmers kept finding their submissions being rejected due
> to his changes not passing the regression tests.
True. And appropriate for any bad habit.
But not relevant here. The question is "would a slightly different
rule be better for Ada". Not "what are the current rules of Ada".
Although it is true that some people in this discussion need
refreshers on that ...
> What do we do with Mr. Hymen Rosen? For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.
ok.
--
-- Stephe
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:44 ` Hyman Rosen
2004-02-25 20:45 ` Randy Brukardt
@ 2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
2004-02-26 15:24 ` Hyman Rosen
1 sibling, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-26 9:44 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>The rules of Ada require that for "and", both
>>>operands are evaluated!
>> No, it doesn't.
>
>ARM 4.5/11 says
> "The two operands of an expression of the form X op Y,
> where op is a binary operator, are evaluated in an
> arbitrary order, as for any function_call (see 6.4)."
>
>Where do you find permission for Ada to not evaluate one
>operand of an "and" or "or" expression?
In "arbitrary"? ;-)
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
@ 2004-02-26 15:24 ` Hyman Rosen
2004-02-26 17:33 ` Vinzent 'Gadget' Hoefler
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 15:24 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
>
> In "arbitrary"? ;-)
Being permitted to do some things in arbitrary order certainly
does not give permission to omit doing some of them. The ARM
does not say that an arbitrary number of operands are evaluated,
it says that the operands are evaluated in arbitrary order.
This is not Wonderland, where words mean exactly what you want
them to.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 15:24 ` Hyman Rosen
@ 2004-02-26 17:33 ` Vinzent 'Gadget' Hoefler
0 siblings, 0 replies; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-26 17:33 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>>
>> In "arbitrary"? ;-)
>
[Disagreement]
>This is not Wonderland, where words mean exactly what you want
>them to.
Should I have marked the Smiley Red and with an additional
"blink"-Attribute? Perhaps some alarming sound, too?
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 15:53 ` Hyman Rosen
2004-02-25 16:05 ` Vinzent 'Gadget' Hoefler
@ 2004-02-25 16:34 ` Preben Randhol
2004-02-25 16:45 ` Hyman Rosen
2004-02-25 16:35 ` Preben Randhol
2 siblings, 1 reply; 203+ messages in thread
From: Preben Randhol @ 2004-02-25 16:34 UTC (permalink / raw)
On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>>
>> |if (Sqrt (x) > 5.0) and b then ...
>
> How would knowing that b is false help the compiler not call the
> costly operation?
isn't
if (undecided) and false then
the same as
if false then
?
Only in the case that b is true is the evaluation of needed Sqrt (x) > 5.0
Or have I missed som point here?
--
"Saving keystrokes is the job of the text editor, not the programming
language."
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 15:53 ` Hyman Rosen
2004-02-25 16:05 ` Vinzent 'Gadget' Hoefler
2004-02-25 16:34 ` Preben Randhol
@ 2004-02-25 16:35 ` Preben Randhol
2004-02-25 16:56 ` Hyman Rosen
2 siblings, 1 reply; 203+ messages in thread
From: Preben Randhol @ 2004-02-25 16:35 UTC (permalink / raw)
On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>
> If the compiler knows enough about Sqrt to know that it has no side
> effects, then it will have no problem checking b first even if you
> write (sqrt(x) > 5.0 and then b).
Well
if sqrt(x) > 5.0 and then b then
is the same as
if sqrt(x) > 5.0 then
if b then
--
"Saving keystrokes is the job of the text editor, not the programming
language."
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:35 ` Preben Randhol
@ 2004-02-25 16:56 ` Hyman Rosen
2004-02-25 17:11 ` Preben Randhol
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 16:56 UTC (permalink / raw)
Preben Randhol wrote:
> if sqrt(x) > 5.0 and then b then
>
> is the same as
>
> if sqrt(x) > 5.0 then
> if b then
Yes, so? As I said, if the compiler knows that sqrt(x)
is free of side effects, it can go ahead and evaluate
b first and never call sqrt(x) if b is false.
That's true in both forms above. It doesn't matter how
you write it. If sqrt(x) is free of side effects, you
cannot know whether it has been called, as far as the
language definition is concerned.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:56 ` Hyman Rosen
@ 2004-02-25 17:11 ` Preben Randhol
2004-02-25 17:33 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Preben Randhol @ 2004-02-25 17:11 UTC (permalink / raw)
On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Yes, so? As I said, if the compiler knows that sqrt(x)
> is free of side effects, it can go ahead and evaluate
> b first and never call sqrt(x) if b is false.
> That's true in both forms above. It doesn't matter how
> you write it. If sqrt(x) is free of side effects, you
> cannot know whether it has been called, as far as the
> language definition is concerned.
My point was that when you use the and then you tell the compiler to
evaluate left-side before right. Whereas if you use only and it is not
given which side will be evaluated first. At least I thought so.
--
"Saving keystrokes is the job of the text editor, not the programming
language."
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 17:11 ` Preben Randhol
@ 2004-02-25 17:33 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 17:33 UTC (permalink / raw)
Preben Randhol wrote:
> My point was that when you use the and then you tell the compiler to
> evaluate left-side before right. Whereas if you use only and it is not
> given which side will be evaluated first. At least I thought so.
Yes, that's correct. However, program behavior is always subject to
the "as if" convention. That is, the program must have observable
behavior as if the compiler did things in the order that the language
specified, but that observable behavior is limited by the language
definition to things like I/O, calling imported subprograms, and some
other stuff that can be loosely categorized as side-effects.
In the proposed case of (sqrt(x) > 0.5 and b), if sqrt(x) has side
effects it must be evaluated regardless of the value of b, and if
it has no side effects you cannot know if it has been evaluated, and
so the compiler may evaluate b first and never evaluate sqrt(x) at
all. The latter holds even if you write (sqrt(x) > 0.5 and then b).
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 15:02 ` Hyman Rosen
2004-02-25 15:43 ` Vinzent 'Gadget' Hoefler
@ 2004-02-25 15:44 ` Hyman Rosen
2004-02-25 16:10 ` Robert I. Eachus
2 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 15:44 UTC (permalink / raw)
Hyman Rosen wrote:
> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).
And I should add that the same holds true for associativity. If you
write a + b + c and "+" is user-defined, the call is "+"("+"(a, b), c)
and never "+"(a, "+"(b, c)). The freedom to use other associations is
only for predefined operators.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 15:02 ` Hyman Rosen
2004-02-25 15:43 ` Vinzent 'Gadget' Hoefler
2004-02-25 15:44 ` Hyman Rosen
@ 2004-02-25 16:10 ` Robert I. Eachus
2004-02-25 16:50 ` Hyman Rosen
2004-02-27 5:31 ` Stephen Leake
2 siblings, 2 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-25 16:10 UTC (permalink / raw)
Hyman Rosen wrote:
> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).
Absolutely wrong. If I or any other Ada programmer defines an abstract
type Foo, and it makes sense to add Integers to Foo, and the semantics
of addition are commutative, I will declare:
function "+"(L: Foo; R: Integer) return Foo is...
function "+"(L: Integer; R: Foo) return Foo
is begin return R+L; end "+";
This is standard programming practice because it reflects the underlying
semantics. In fact I will probably provide "-" operations as well,
defined as return L+(-R) and R+(-L) respectively. (And yes, sometimes I
will even provide an exception handler to deal with subrtracting
Integer'First..)
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 16:10 ` Robert I. Eachus
@ 2004-02-25 16:50 ` Hyman Rosen
2004-02-26 13:41 ` Robert I. Eachus
2004-02-27 5:31 ` Stephen Leake
1 sibling, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 16:50 UTC (permalink / raw)
Robert I. Eachus wrote:
> Absolutely wrong. ... I will declare...
You are describing your programming practices.
Your practices do not necessarily represent the
philosophy of the language. In any case, when I
said that a + b becomes "+"(a, b) and not "+"(b, a)
I was not "absolutely wrong" but "absolutely right".
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:50 ` Hyman Rosen
@ 2004-02-26 13:41 ` Robert I. Eachus
2004-02-26 15:44 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-26 13:41 UTC (permalink / raw)
Hyman Rosen wrote:
> Robert I. Eachus wrote:
>
>> Absolutely wrong. ... I will declare...
>
>
> You are describing your programming practices.
> Your practices do not necessarily represent the
> philosophy of the language. In any case, when I
> said that a + b becomes "+"(a, b) and not "+"(b, a)
> I was not "absolutely wrong" but "absolutely right".
No, you were absolutely wrong as usual. The order of evaluation of the
parameters to "+" is undefined whether the "+" is user defined or
language defined. To quote 6.4(10): "These evaluations are done in an
arbitrary order." There is even an explicit footnote at 4.5(14) that
explains that this applies to predefined operators as well as user
defined operators.
I should stop wrestling with pigs. But I would like to preserve this
newsgroup as a place where users can get reliable advice on language
issues. So I have to keep putting up these placards that say ignore
anything Hyman Rosen says about Ada language issues.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 13:41 ` Robert I. Eachus
@ 2004-02-26 15:44 ` Hyman Rosen
2004-02-28 17:34 ` Robert I. Eachus
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 15:44 UTC (permalink / raw)
Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> In any case, when I
>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>> I was not "absolutely wrong" but "absolutely right".
>
> No, you were absolutely wrong as usual. The order of evaluation of the
> parameters to "+" is undefined whether the "+" is user defined or
> language defined.
Where did I say that the order of evaluation of the operands was
defined? V'G'H argued that the philosophy of Ada was that a + b
and b + a are the same. I pointed out that for user-defined "+",
when you write a + b, the function is called with a as the Left
operand and b as the Right, never the reverse.
> I should stop wrestling with pigs.
You are so eager to believe I am wrong about everything I say that
you are not reading what I say. Stop it. You're just going to annoy
the pig :-)
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 15:44 ` Hyman Rosen
@ 2004-02-28 17:34 ` Robert I. Eachus
2004-02-29 3:51 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-28 17:34 UTC (permalink / raw)
Hyman Rosen wrote:
> Robert I. Eachus wrote:
>
>> Hyman Rosen wrote:
>>
>>> In any case, when I
>>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>>> I was not "absolutely wrong" but "absolutely right".
>>
>>
>> No, you were absolutely wrong as usual. The order of evaluation of
>> the parameters to "+" is undefined whether the "+" is user defined or
>> language defined.
>
>
> Where did I say that the order of evaluation of the operands was
> defined? V'G'H argued that the philosophy of Ada was that a + b
> and b + a are the same. I pointed out that for user-defined "+",
> when you write a + b, the function is called with a as the Left
> operand and b as the Right, never the reverse.
>
> > I should stop wrestling with pigs.
>
> You are so eager to believe I am wrong about everything I say that
> you are not reading what I say. Stop it. You're just going to annoy
> the pig :-)
No, it is trying to teach a pig to sing that annoys the pig. When you
wrestle with pigs, you just get dirty, and the pig enjoys it. (Of
course, if the pig is a pet and kept clean, the person doing the
wrestling may stay clean and actually want the pig to enjoy it.) But
this is not a discussion of ENGLISH semantics ;-)
MY point, which apparently you missed, was not that Ada compilers are
allowed to ignore the order of parameters (except of course with named
notation). It is that you will find lots of places in the standard where
order independent SEMANTICS occurs, for example in 13.7.1(7). In those
cases the usual implementation (in this case of package
System.Storage_Elements) will simplify things by using parameter
flipping and pragma Inline. If we were to change the semantics of Ada
to require left-to-right evaluation, what should be done with these
functions, especially when they are in-lined? A workable rule probably
could be written, but it is the sort of thing you have to look at with a
proposal like yours.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-28 17:34 ` Robert I. Eachus
@ 2004-02-29 3:51 ` Hyman Rosen
2004-02-29 14:10 ` Robert I. Eachus
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-29 3:51 UTC (permalink / raw)
Robert I. Eachus wrote:
> It is that you will find lots of places in the standard where
> order independent SEMANTICS occurs, for example in 13.7.1(7). In those
> cases the usual implementation (in this case of package
> System.Storage_Elements) will simplify things by using parameter
> flipping and pragma Inline. If we were to change the semantics of Ada
> to require left-to-right evaluation, what should be done with these
> functions, especially when they are in-lined? A workable rule probably
> could be written, but it is the sort of thing you have to look at with a
> proposal like yours.
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.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-29 3:51 ` Hyman Rosen
@ 2004-02-29 14:10 ` Robert I. Eachus
2004-02-29 15:37 ` Jon S. Anthony
2004-03-01 17:38 ` Hyman Rosen
0 siblings, 2 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-29 14:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-29 14:10 ` Robert I. Eachus
@ 2004-02-29 15:37 ` Jon S. Anthony
2004-03-01 17:38 ` Hyman Rosen
1 sibling, 0 replies; 203+ messages in thread
From: Jon S. Anthony @ 2004-02-29 15:37 UTC (permalink / raw)
"Robert I. Eachus" <rieachus@comcast.net> writes:
> 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))
??? This is ill formed Common Lisp. Presumably you mean:
(defun twiddle-thumbs (thumb1 thumb2)
(twiddle-thumbs thumb2 thumb1))
Which if called, say by:
...
(twiddle-thumbs l-thumb r-thumb)
...
will produce an infinite loop (and thus the "joke" part).
BTW, Lisp _does_ require l-to-r argument evaluation in calls.
> That really sums up the issue I was bringing up. The second function
> in that particular pair of functions is probably defined by:
I'm fairly sure you are referring to the pair of functions mentioned
in HR's comment, but just so no one else gets confused: There is only
one function in the Lisp given, not two.
> 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.
It's irrelevant as you (the compiler writer) simply arrange to have
the arguments evaluated in the correct order and then passed. Here is
an implementation of such a pair (in Lisp, since you can do this sort
of stuff at the user/programmer level):
(defmacro +one (l r)
`(+ ,l ,r))
(defmacro +two (l r)
(with-gensyms (ul ur)
`(let ((,ul ,l) ; evaluate l
(,ur ,r)); evaluate r
(+one ,ur ,ul))))
This is semantically (at compilation level semantics) the same as:
(defun +one (l r)
(+ l r))
(defun +two (l r)
(+one r l))
(declaim (inline +one +two))
What gets generated at a call in some code:
(macroexpand-1 '(+one (sqrt 8) (expt 2 32)))
==> (+ (sqrt 8) (expt 2 32))
(macroexpand-1 '(+two (sqrt 8) (expt 2 32)))
==>
(LET ((#:G87115 (SQRT 8)) (#:G87116 (EXPT 2 32)))
(+ONE #:G87116 #:G87115))
(macroexpand '(+two (sqrt 8) (expt 2 32))) ; Fully expand
==>
(LET ((#:G87135 (SQRT 8)) (#:G87136 (EXPT 2 32)))
(+ #:G87136 #:G87135))
(+two (sqrt 8) (expt 2 32))
==> 4.2949673e+9
So, arguments to both are always evaluated in the correct order, even
though one compiles directly inline to a call of the other which is
also compiled inline. No big deal.
/Jon
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-29 14:10 ` Robert I. Eachus
2004-02-29 15:37 ` Jon S. Anthony
@ 2004-03-01 17:38 ` Hyman Rosen
2004-03-02 3:05 ` Robert I. Eachus
1 sibling, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-03-01 17:38 UTC (permalink / raw)
Robert I. Eachus wrote:
> Now, when do you apply your left-to-right requirement, before or after
> the pragma Inline has been applied?
Pragma Inline is not exactly "applied". It is a hint to the compiler
that it would be advantageous for certain code to be expanded inline
as opposed to being called through the "normal" subprogram mechanism.
It does not have any effect on the meaning of Ada code which uses such
a subprogram, and therefore would not have any meaning when considering
l-to-r behavior.
> If an expression contains two non-pure, non-predefined functions they
> must be evaluated in canonical order instead of "some order."
This gets you most of the way there. It would still leave pathological
cases like (I + Inc(I)) unspecified, but I can't imagine that there's
any real code out there which cares.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-03-01 17:38 ` Hyman Rosen
@ 2004-03-02 3:05 ` Robert I. Eachus
2004-03-02 7:08 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-03-02 3:05 UTC (permalink / raw)
Hyman Rosen wrote:
> Pragma Inline is not exactly "applied". It is a hint to the compiler
> that it would be advantageous for certain code to be expanded inline
> as opposed to being called through the "normal" subprogram mechanism.
> It does not have any effect on the meaning of Ada code which uses such
> a subprogram, and therefore would not have any meaning when considering
> l-to-r behavior.
There you go again. What you say seems to make sense, but it is not
correct. To quote from 11.6(6): "An independent subprogram is one that
is defined outside the library unit containing the construct whose check
failed, and has no Inline pragma applied to it."
So although whether the compiler does follow the advice of a pragma
Inline, it has semantic effects. Those effects happen to be important
in this particular case. The appearance of an independent subprogram
prevents the compiler from doing some reorderings. Put in the pragma
Inline, and the code might not be inlined by the compiler, but the
compiler could move other code from before to after it or vice-versa.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 3:05 ` Robert I. Eachus
@ 2004-03-02 7:08 ` Hyman Rosen
2004-03-02 8:48 ` Jacob Sparre Andersen
2004-03-02 17:12 ` Robert I. Eachus
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-03-02 7:08 UTC (permalink / raw)
Robert I. Eachus wrote:
> So although whether the compiler does follow the advice of a pragma
> Inline, it has semantic effects.
The same section says
"The permissions granted by this clause can have an effect on the
semantics of a program only if the program fails a language-defined
check."
So unless you're coding in a way where you expect to cause and catch
l-d checks, it won't matter.
Also, if I read that section correctly, in a sequence of code like this
a := 0;
b := c + d;
e := f + g;
h := i + j;
a := 1 / a;
it is possible that only the assignment to a will have occurred when the
exception handler from the division by zero is executed, is that correct?
Doesn't that make catching failures of language-defined checks useless?
You will know that something bad happened, but you won't know which objects
in your program are abnormal.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 7:08 ` Hyman Rosen
@ 2004-03-02 8:48 ` Jacob Sparre Andersen
2004-03-02 15:24 ` Hyman Rosen
2004-03-02 17:12 ` Robert I. Eachus
1 sibling, 1 reply; 203+ messages in thread
From: Jacob Sparre Andersen @ 2004-03-02 8:48 UTC (permalink / raw)
Hyman Rosen wrote:
> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.
Yes (assuming your functions haven't got side effects).
> Also, if I read that section correctly, in a sequence of code like
> this
> a := 0;
> b := c + d;
> e := f + g;
> h := i + j;
> a := 1 / a;
> it is possible that only the assignment to a will have occurred when
> the exception handler from the division by zero is executed, is that
> correct?
I _think_ (haven't got the ARM around right now) that in case the
object b, e and h aren't accessible/used after the exception has been
raised, you are correct that the only thing that actually happens in
the following statements is that an exception is raised by the
division by zero. This view is based on the principle of �same
external effect�.
If b, e or h on the other hand is accessible/used after the exception
has been raised, then the (or some of the) three intermediate
statements have to be executed as well to give the same external
effect.
> Doesn't that make catching failures of language-defined checks
> useless? You will know that something bad happened, but you won't
> know which objects in your program are abnormal.
No. You should know from the sequence the statements are written in,
which statements have been executed if it has an effect on which of
the _accessible_ objects are in which state.
Jacob (who isn't a LL and didn't look it up in the ARM)
--
�What fun is it being "cool" if you can't wear a sombrero?�
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-03-02 8:48 ` Jacob Sparre Andersen
@ 2004-03-02 15:24 ` Hyman Rosen
2004-03-02 15:42 ` Jacob Sparre Andersen
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-03-02 15:24 UTC (permalink / raw)
Jacob Sparre Andersen wrote:
> No. You should know from the sequence the statements are written in,
> which statements have been executed if it has an effect on which of
> the _accessible_ objects are in which state.
I don't think so, given 11.6(6).
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-03-02 15:24 ` Hyman Rosen
@ 2004-03-02 15:42 ` Jacob Sparre Andersen
2004-03-02 16:33 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Jacob Sparre Andersen @ 2004-03-02 15:42 UTC (permalink / raw)
Hyman Rosen wrote:
> Jacob Sparre Andersen wrote:
> > No. You should know from the sequence the statements are written
> > in, which statements have been executed if it has an effect on
> > which of the _accessible_ objects are in which state.
>
> I don't think so, given 11.6(6).
Right!
But if this really is a serious problem for you, you can handle it by
putting each of the five assignments in your sequence of statements
within its own begin-exception-end block. Assuming that I have
understood 11.6(6) correctly by now.
Jacob
--
"Those who profess to favor freedom and yet depreciate
agitation, are people who want crops without ploughing the
ground; they want rain without thunder and lightning; they
want the ocean without the roar of its waters."
-- Frederick Douglas
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 15:42 ` Jacob Sparre Andersen
@ 2004-03-02 16:33 ` Hyman Rosen
2004-03-02 22:06 ` Robert I. Eachus
2004-03-02 22:43 ` Randy Brukardt
0 siblings, 2 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-03-02 16:33 UTC (permalink / raw)
Jacob Sparre Andersen wrote:
> But if this really is a serious problem for you, you can handle it by
> putting each of the five assignments in your sequence of statements
> within its own begin-exception-end block.
That's not really the point. If I know in micro-detail where a check
is failing, I could just as easily make it not fail. What I expected
(which will probably earn me another blast from RE for not getting
the Ada mindset) was that the reason for l-d checks is to prevent the
kind of errors you find in C, namely undetected erroneous changes that
trigger problems at some remove from the place where they occurred.
It seems to me that the Ada rules allow the same sort of thing to
happen - if I have a handler at a high level for a language-defined
error, it's possible that any number of objects may have been left in
an abnormal state when the exception triggered, and I will encounter
erroneous (and possibly undetected) behavior at some later point.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-03-02 16:33 ` Hyman Rosen
@ 2004-03-02 22:06 ` Robert I. Eachus
2004-03-02 22:43 ` Randy Brukardt
1 sibling, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-03-02 22:06 UTC (permalink / raw)
Hyman Rosen wrote:
> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail. What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.
First of all, on this point I agree with you that the Ada 95 rules go
too far. Fortunately, if you look at the example I posted, most Ada
compilers are very careful about taking advantage of the 11.6(6)
freedoms when exceptions can happen.
The real problem is that it is very hard to write a rule that makes
sense given the way today's CPUs are built. The CPU will reorder
instructions at run-time, and only some CPUs will pretend, if an
instruction causes an interrupt, that the ordering was precise. I could
probably reference half a dozen architecture manuals for you, that
detail exactly how precise and non-precise interrupts are serviced. But
it is lots of really boring trivia to sort through to figure out what
happens in a case that you might care about. But I do read those
manuals, thoroughly at least for most SPARC family processors, x86
processors and now AMD64/IA-32e CPUs.
You have to remember is that the implementations vary, even within a
processor family, and worse some processors have multiple modes, with
different interrupt behavior. So the current (Ada 95) RM rules really
amount to do what makes sense on the real hardware--because the compiler
compiles to an ISA, and for many ISAs, the rules change from
implementation to implementation.
Fortunately, as the program I just posted shows, most compilers still
obey the old Ada 83 meta-rule: "Thou shalt not reason from
erroneousness." The program as written is (intentionally) erroneous.
Not causes a bounded error, which is a much more tightly limited case,
but erroneous.
Would I write code like that 'for real'? Of course not. But it doesn't
prevent me from grumbling about how difficult it can be for a programmer
to avoid erroneousness in some contexts.
(Technically what you have to do is write subprograms that handle
exceptions internally as follows:
procedure Foo(...) is
-- object declarations here should never raise an exception.
-- put things that can in a nested block.
begin
declare
-- potentially problematical variables
begin
-- do any additional checking here, but don't assign to any
-- out or in out parameters.
-- firewall This is usually a call to some external procedure or
-- function that is not inlined. This can be, and often is in
-- code that I write, a call that is needed anyway.
-- do any assignments to globals or parameters here.
exception
when Constraint_Error =>
-- fix the problem either by using a different
-- algorithm, or by a nested call to Foo with modified parameters.
when others => raise;
-- or whatever, it is usually Constraint_Error that takes all the
-- work, and any other exceptions are passed back to the caller.
end; -- nested block.
end Foo;
All that looks like a lot of work, but it isn't usually. It is just
that most programmers Ada or otherwise have no idea of what it takes to
write a subprogram that actually deals with Constraint_Error instead of
just renaming it or letting it propagate to the caller.
To give just one example, think about an Inverse function for matrices.
There are matrices for which the inverse is well defined, there are
cases where the matix is singular, and there is a third group of cases
where the matrix is ill conditioned or stiff. Often it takes a lot more
CPU cycles to run the cases which can deal with ill-conditioned or stiff
matrices, so you really do want to try say, simple LU decomposition first.
If you do go to that effort, putting the firewall call in is no big
deal. Writing the code so that you can begin over when needed is often
more work, but in this case you are not inverting the matrix in place
(unless you pass the matrix with an access parameter).
Now if anyone wants to submit a suggestion to Ada-Comment suggesting
that there actually be a language defined procedure Firewall that does
nothing but what its name implies, fine. Personally I find it easy
enough to have my own version around and call it.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 16:33 ` Hyman Rosen
2004-03-02 22:06 ` Robert I. Eachus
@ 2004-03-02 22:43 ` Randy Brukardt
1 sibling, 0 replies; 203+ messages in thread
From: Randy Brukardt @ 2004-03-02 22:43 UTC (permalink / raw)
"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1078245216.689285@master.nyc.kbcfp.com...
> Jacob Sparre Andersen wrote:
> > But if this really is a serious problem for you, you can handle it by
> > putting each of the five assignments in your sequence of statements
> > within its own begin-exception-end block.
>
> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail.
Not really. Try writing a multiply routine that detects overflow without
handling the exception.
> What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.
Handling l-d checks requires great care. It's generally only safe to do so
in a very narrow section of code (like the overflow check mentioned above),
or in a very broad chunk of code (the whole subsystem). Usually, you just
want to log them and either exit or reinitialize everything and start over.
Ada doesn't really support continuation from constraint_error or
storage_error.
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-03-02 7:08 ` Hyman Rosen
2004-03-02 8:48 ` Jacob Sparre Andersen
@ 2004-03-02 17:12 ` Robert I. Eachus
2004-03-02 17:28 ` Georg Bauhaus
1 sibling, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-03-02 17:12 UTC (permalink / raw)
Hyman Rosen wrote:
> The same section says
> "The permissions granted by this clause can have an effect on the
> semantics of a program only if the program fails a language-defined
> check."
>
> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.
Exactly correct. But I do write code that deals with Constraint_Error,
and has to do so correctly--whatever that means in that particular library.
> Also, if I read that section correctly, in a sequence of code like this
> a := 0;
> b := c + d;
> e := f + g;
> h := i + j;
> a := 1 / a;
> it is possible that only the assignment to a will have occurred when the
> exception handler from the division by zero is executed, is that correct?
> Doesn't that make catching failures of language-defined checks useless?
> You will know that something bad happened, but you won't know which objects
> in your program are abnormal.
In fact for this sequence the compiler can generate code that does no
assignments and always raises Constraint_Error. I wrote a little program:
with Ada.Text_IO; use Ada.Text_IO;
procedure Hyman_Example is
A,B,C,D,E,F,G,H,I,J: Integer := 1;
begin
begin
a := 0;
b := c + d;
e := f + g;
h := i + j;
a := 1 / a;
exception when Constraint_Error =>
Put_Line("Constraint_Error Raised. a = " & Integer'Image(A)
& " b = " & Integer'Image(B)
& " e = " & Integer'Image(E)
& " h = " & Integer'Image(H));
end;
end Hyman_Example;
And was actually surprised that GNAT didn't give me a warning and do
just that. I suspect that GNAT was being 'nice' because it saw a
declare block there to handle Constraint_Error. I could try making the
declare block a library unit procedure and see what happens.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 17:12 ` Robert I. Eachus
@ 2004-03-02 17:28 ` Georg Bauhaus
2004-03-02 22:09 ` Robert I. Eachus
0 siblings, 1 reply; 203+ messages in thread
From: Georg Bauhaus @ 2004-03-02 17:28 UTC (permalink / raw)
Robert I. Eachus <rieachus@comcast.net> wrote:
:
: And was actually surprised that GNAT didn't give me a warning and do
: just that.
Maybe I just haven't understood, however:
Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)
11. a := 1 / a;
|
>>> warning: division by zero
>>> warning: "Constraint_Error" will be raised at run time
18 lines: No errors, 2 warnings
(further warnings about C, D, F, G, I, J not being modified
but not declared constant, if requested.)
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 17:28 ` Georg Bauhaus
@ 2004-03-02 22:09 ` Robert I. Eachus
2004-03-04 0:08 ` Georg Bauhaus
0 siblings, 1 reply; 203+ messages in thread
From: Robert I. Eachus @ 2004-03-02 22:09 UTC (permalink / raw)
Georg Bauhaus wrote:
> Robert I. Eachus <rieachus@comcast.net> wrote:
> :
> : And was actually surprised that GNAT didn't give me a warning and do
> : just that.
>
> Maybe I just haven't understood, however:
> Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)
>
> 11. a := 1 / a;
> |
> >>> warning: division by zero
> >>> warning: "Constraint_Error" will be raised at run time
>
> 18 lines: No errors, 2 warnings
>
> (further warnings about C, D, F, G, I, J not being modified
> but not declared constant, if requested.)
Hmmm. What version, and with which command line parameters? I actually
used: gnatmake -gnato -f -O3 hyman_example.adb With GNAT 3.15p for
Windows/x86.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-03-02 22:09 ` Robert I. Eachus
@ 2004-03-04 0:08 ` Georg Bauhaus
0 siblings, 0 replies; 203+ messages in thread
From: Georg Bauhaus @ 2004-03-04 0:08 UTC (permalink / raw)
Robert I. Eachus <rieachus@comcast.net> wrote:
:
: Hmmm. What version, and with which command line parameters? I actually
: used: gnatmake -gnato -f -O3 hyman_example.adb With GNAT 3.15p for
: Windows/x86.
GCC 3.4 from last year, on GNU/Linux, the div by 0 warning is issued with
no options present (except -gnatv), the could-be-declared-constant warnings
follow after adding -gnatwa.
-- Georg
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 16:10 ` Robert I. Eachus
2004-02-25 16:50 ` Hyman Rosen
@ 2004-02-27 5:31 ` Stephen Leake
1 sibling, 0 replies; 203+ messages in thread
From: Stephen Leake @ 2004-02-27 5:31 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net> writes:
> Hyman Rosen wrote:
>
> > But Ada does not have that philosophy, so that cannot be the reason
> > to maintain the feature. When "+" is a user-defined subprogram, its
> > operands are always passed in the order written; a + b is always
> > invoked as "+"(a, b) and never as "+"(b, a).
>
> Absolutely wrong.
That's an odd thing to say!
> If I or any other Ada programmer defines an abstract type Foo, and
> it makes sense to add Integers to Foo, and the semantics of addition
> are commutative, I will declare:
>
> function "+"(L: Foo; R: Integer) return Foo is...
Let's call this function 1.
> function "+"(L: Integer; R: Foo) return Foo is begin return R+L; end
> "+";
and function 2.
Yes. and the reason you need to do this is that the Ada _language_
requires that 'a + b' _always_ be equivalent to "+" (a, b), not "+"
(b, a), as Hymen said!
To be more concrete:
declare
a : Foo;
b : Integer;
c : integer;
d : integer;
begin
c := a + b; -- calls function 1
d := b + a; -- calls function 2
end;
If Ada were allowed to use "+" (b, a) for 'a + b', you would not need
function 2 to compute d.
--
-- Stephe
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 0:44 ` Stephen Leake
2004-02-25 9:21 ` Dmitry A. Kazakov
2004-02-25 9:33 ` David Starner
@ 2004-02-25 12:01 ` Marin David Condic
2004-02-25 20:41 ` Randy Brukardt
2004-02-25 22:05 ` Jim Rogers
4 siblings, 0 replies; 203+ messages in thread
From: Marin David Condic @ 2004-02-25 12:01 UTC (permalink / raw)
That is an issue I think we Ada fans often get caught up in. "Well, in
*theory* an Ada compiler could do blah blah blah...." But if, in
*practice*, none of them do and none of them have any plans to do so,
then effectively "The Language" doesn't do it. A good example is when
people post here asking "Does Ada have garbage collection?" We tell them
the standard allows it, but nobody does it. Do they care that the
standard allows it if they can't get a compiler that does it? The same
goes for other issues like efficiency. A feature might theoretically be
implementable in an efficient manner, but if nobody does it well in
practice, you get the accusation "Ada is slow..." and its hard to argue
against.
There is a real distinction between what the standard says and what
might exist by way of implementations, but for most practical purposes,
average developers don't make that distinction. Hence, there is a de
facto "standard" which cannot be ignored.
MDC
Stephen Leake wrote:
>
> 2) Does anyone have a real example of a compiler taking advantage of
> the evaluation order freedom to speed up a program?
>
> I have not heard anyone respond to 2), which is supposedly the reason
> the freedom is there. If no compiler actually takes advantage of it,
> it's not worth having.
>
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Face it ladies, its not the dress that makes you look fat.
Its the FAT that makes you look fat."
-- Al Bundy
======================================================================
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 0:44 ` Stephen Leake
` (2 preceding siblings ...)
2004-02-25 12:01 ` Marin David Condic
@ 2004-02-25 20:41 ` Randy Brukardt
2004-02-25 22:05 ` Jim Rogers
4 siblings, 0 replies; 203+ messages in thread
From: Randy Brukardt @ 2004-02-25 20:41 UTC (permalink / raw)
"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.20.1077669870.327.comp.lang.ada@ada-france.org...
> 2) Does anyone have a real example of a compiler taking advantage of
> the evaluation order freedom to speed up a program?
Janus/Ada will take advantage of this to reduce pending floating point
results on the Intel CPUs. These are quite expensive because the floating
point stack is very short, so it has to be clear before any subprogram call.
Thus the pending results have to be spilled to memory (and later reloaded),
rather than just using registers.
So, if you have an expression like:
B := V + F(...);
Janus/Ada may make the call first, in order to avoid the pending floating
point operation.
Of course, if F changes the value of V, then you'll get a different answer.
Of course, the compiler does not know what's in the body of F. Indeed, even
if it could see the body of F, it couldn't assume that it doesn't modify V,
as it could be changed and recompiled without the call code being changed.
Thus, requiring a particular order of evaluation would make this
optimization impossible. (Even if V is a local variable, it could be changed
by overlays or other nasty code.)
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 0:44 ` Stephen Leake
` (3 preceding siblings ...)
2004-02-25 20:41 ` Randy Brukardt
@ 2004-02-25 22:05 ` Jim Rogers
2004-02-25 22:19 ` Hyman Rosen
4 siblings, 1 reply; 203+ messages in thread
From: Jim Rogers @ 2004-02-25 22:05 UTC (permalink / raw)
Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.20.1077669870.327.comp.lang.ada@ada-france.org>...
> I think Hyman has two valid points:
>
> 1) if the language specified left-to-right order, there would never be
> a need to "kill the original smart-ass programmer"
>
> 2) Does anyone have a real example of a compiler taking advantage of
> the evaluation order freedom to speed up a program?
But how does his order of evaluation work with named notation?
Is the order determined by the order of the formal parameters, or by
the order of the actual parameters?
In Ada it is not as easy to determine parameter order because of
named notation.
Jim Rogers
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 22:05 ` Jim Rogers
@ 2004-02-25 22:19 ` Hyman Rosen
2004-02-26 9:34 ` Dmitry A. Kazakov
` (3 more replies)
0 siblings, 4 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-25 22:19 UTC (permalink / raw)
Jim Rogers wrote:
> But how does his order of evaluation work with named notation?
I would go with the order of the actual parameters,
not the order of the formal parameters. One goal of
specifying evaluation order is to have unsurprising
behavior, so saying
Battery(Catcher => GetName, Pitcher => GetName);
should assign the first name read to Catcher and the
second to Pitcher, regardless of the order of the formal
parameters of Battery.
I can't at the moment think of a good reason for doing it
the other way from the programmer's point of view, rather
than for the convenience of the compiler.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 22:19 ` Hyman Rosen
@ 2004-02-26 9:34 ` Dmitry A. Kazakov
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
` (2 subsequent siblings)
3 siblings, 0 replies; 203+ messages in thread
From: Dmitry A. Kazakov @ 2004-02-26 9:34 UTC (permalink / raw)
On Wed, 25 Feb 2004 17:19:50 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:
>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
> Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.
>
>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view, rather
>than for the convenience of the compiler.
Discriminants are exposed as members and can be used in named
associations. From any point of view they are better to be evaluated
first:
type Buffer (Size : Integer) is record
Data : String (1..Size);
end record;
Note that the aggregate:
Buffer'(Data => ..., Size => ...)
is quite legal. So by fixing the evaluation order here the compiler
will be forced to make a temporal copy of the Data field, because it
will be unable to create Buffer not knowing Size.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-25 22:19 ` Hyman Rosen
2004-02-26 9:34 ` Dmitry A. Kazakov
@ 2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
2004-02-26 15:48 ` Hyman Rosen
2004-02-27 23:37 ` Randy Brukardt
2004-02-26 12:42 ` Wojtek Narczynski
2004-02-26 13:50 ` Robert I. Eachus
3 siblings, 2 replies; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-26 9:44 UTC (permalink / raw)
Hyman Rosen wrote:
>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
> Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.
Yes, and that is a very good example on how to write bad code. First:
GetName is obviously a function with side-effect, second it relies on
a specific calling order.
If you want a specific order, do it explicitely:
|Tmp_Name_1 := GetName;
|Tmp_Name_2 := GetName;
|
|Battery(Catcher => Tmp_Name_1, Pitcher => Tmp_Name_2);
>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view,
Well, my point of view to the original code would be that it doesn't
matter which name gets assigned to which parameter.
>rather than for the convenience of the compiler.
Yes, true. But Ada is - like a lot of others - a programming language
that is supposed to get compiled some day. And sometimes language
designers should keep an eye on this if they want a language to be
used outside of purely theoretical and/or educational areas.
So it might be possible that in the parsing/compiling process the
order specified in the named notation simply gets reordered to the
order of how the parameters are declared. Well, even this still
doesn't mean, that this would be the order in which the functions are
called in the end.
I think, all this discussion about execution order is a little bit
senseless when today we have processors that do explicit instruction
reordering and even have parallel execution support. Even if the
compiler issues code where the execution order is fixed that doesn't
mean that the processor will execute it this way. And you don't want
the compiler to emit one serializing instruction after another just to
make sure that the execution order does not change, do you?
IMO, it is easier to just not rely on side-effects. No side-effects,
no problems.
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
@ 2004-02-26 15:48 ` Hyman Rosen
2004-02-26 17:49 ` Vinzent 'Gadget' Hoefler
2004-02-27 23:37 ` Randy Brukardt
1 sibling, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 15:48 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Yes, and that is a very good example on how to write bad code. First:
> GetName is obviously a function with side-effect, second it relies on
> a specific calling order.
Well, duh. The discussion is about what behavior we want in this case
should we actually define a specific calling order.
> I think, all this discussion about execution order is a little bit
> senseless when today we have processors that do explicit instruction
> reordering and even have parallel execution support.
Not at all. We are discussing the semantics of Ada. How they are
implemented on a processor by the compiler is not relevant.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 15:48 ` Hyman Rosen
@ 2004-02-26 17:49 ` Vinzent 'Gadget' Hoefler
2004-02-26 18:12 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Vinzent 'Gadget' Hoefler @ 2004-02-26 17:49 UTC (permalink / raw)
Hyman Rosen wrote:
>Vinzent 'Gadget' Hoefler wrote:
>> Yes, and that is a very good example on how to write bad code. First:
>> GetName is obviously a function with side-effect, second it relies on
>> a specific calling order.
>
>Well, duh. The discussion is about what behavior we want in this case
>should we actually define a specific calling order.
Yes. But I don't like the idea of inviting programmers to a party "We
have defined the evaluation order - now you can write functions with
side-effects and they behave equally strange on all systems".
>> I think, all this discussion about execution order is a little bit
>> senseless when today we have processors that do explicit instruction
>> reordering and even have parallel execution support.
>
>Not at all. We are discussing the semantics of Ada. How they are
>implemented on a processor by the compiler is not relevant.
It just doesn't make sense to argue about a specific order if the
processor itself changes it when the code gets executed, does it?
Vinzent.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 17:49 ` Vinzent 'Gadget' Hoefler
@ 2004-02-26 18:12 ` Hyman Rosen
2004-02-27 0:55 ` David Starner
0 siblings, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 18:12 UTC (permalink / raw)
Vinzent 'Gadget' Hoefler wrote:
> Yes. But I don't like the idea of inviting programmers to a party "We
> have defined the evaluation order - now you can write functions with
> side-effects and they behave equally strange on all systems".
The idea is to make it not strange, so that you read the code and
immediately understand what it does.
> It just doesn't make sense to argue about a specific order if the
> processor itself changes it when the code gets executed, does it?
Of course it does, in the same way that we can talk about Ada's
support for decimal arithmetic on processors which are unrelentingly
binary. Programming langiage semantics don't have anything to do
with processor semantics.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 18:12 ` Hyman Rosen
@ 2004-02-27 0:55 ` David Starner
0 siblings, 0 replies; 203+ messages in thread
From: David Starner @ 2004-02-27 0:55 UTC (permalink / raw)
On Thu, 26 Feb 2004 13:12:32 -0500, Hyman Rosen wrote:
> The idea is to make it not strange, so that you read the code and
> immediately understand what it does.
Part of the point of the argument is that I don't believe your solution
can change; it's still going to be virtually impossible to follow, it's
just going to be sanctioned as acceptable.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
2004-02-26 15:48 ` Hyman Rosen
@ 2004-02-27 23:37 ` Randy Brukardt
1 sibling, 0 replies; 203+ messages in thread
From: Randy Brukardt @ 2004-02-27 23:37 UTC (permalink / raw)
"Vinzent 'Gadget' Hoefler" <nntp-2004-02@t-domaingrabbing.de> wrote in
message news:t9fr30tnl8rh0ain01qeqq17ottovqdso3@jellix.jlfencey.com...
...
> So it might be possible that in the parsing/compiling process the
> order specified in the named notation simply gets reordered to the
> order of how the parameters are declared.
Right. That's exactly what Janus/Ada does internally for named notation, and
the arguments are evaluated in the order that they get passed; no matter
what order they were passed in.
> IMO, it is easier to just not rely on side-effects. No side-effects, no
problems.
Which was the basic idea behind Pure - a way to declare that functions have
no meaningful side effects. (Caching values and records calls in a
scratchpad aren't meaningful). It's unfortunate that applying the "Pure"
categorization is so difficult. GNAT provides a solution here - pragma
Pure_Function - which essentially declares to the compiler that the function
has no meaningful side effects without any checks. (This pragma is being
considered for Ada 200Y.) One could imagine a coding standard which required
all functions used in non-trivial expressions (that is, not used alone) to
be marked either Pure or Pure_Function.
Randy.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 22:19 ` Hyman Rosen
2004-02-26 9:34 ` Dmitry A. Kazakov
2004-02-26 9:44 ` Vinzent 'Gadget' Hoefler
@ 2004-02-26 12:42 ` Wojtek Narczynski
2004-02-26 12:47 ` Lutz Donnerhacke
2004-02-26 13:50 ` Robert I. Eachus
3 siblings, 1 reply; 203+ messages in thread
From: Wojtek Narczynski @ 2004-02-26 12:42 UTC (permalink / raw)
Hello,
> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
> Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.
How about:
Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName
);
This way the change would not affect current code, and you could
specify partial order.
Regards,
Wojtek
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 12:42 ` Wojtek Narczynski
@ 2004-02-26 12:47 ` Lutz Donnerhacke
2004-02-26 15:56 ` Hyman Rosen
0 siblings, 1 reply; 203+ messages in thread
From: Lutz Donnerhacke @ 2004-02-26 12:47 UTC (permalink / raw)
* Wojtek Narczynski wrote:
> How about:
> Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName);
Very bad. Hard to read. Hard to maintain. Bad Ada-Style.
declare
catcher : constant Name := GetName;
pitcher : constant Name := GetName;
doorman : constant Name := GetName;
begin
Battery(catcher, pitcher, doorman);
end;
Moderate to write, moderate to read and easy to understand/maintain.
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 12:47 ` Lutz Donnerhacke
@ 2004-02-26 15:56 ` Hyman Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 15:56 UTC (permalink / raw)
Lutz Donnerhacke wrote:
> Very bad. Hard to read. Hard to maintain. Bad Ada-Style.
> declare
> catcher : constant Name := GetName;
> pitcher : constant Name := GetName;
> doorman : constant Name := GetName;
> begin
> Battery(catcher, pitcher, doorman);
> end;
> Moderate to write, moderate to read and easy to understand/maintain.
Or, in well-defined Ada,
declare
catcher, pitcher, doorman : constant Name := GetName;
begin
Battery(catcher, pitcher, doorman);
end;
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-25 22:19 ` Hyman Rosen
` (2 preceding siblings ...)
2004-02-26 12:42 ` Wojtek Narczynski
@ 2004-02-26 13:50 ` Robert I. Eachus
2004-02-26 16:00 ` Hyman Rosen
2004-02-27 6:00 ` Stephen Leake
3 siblings, 2 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-26 13:50 UTC (permalink / raw)
Hyman Rosen wrote:
> Jim Rogers wrote:
>
>> But how does his order of evaluation work with named notation?
>
>
> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
> Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.
>
> I can't at the moment think of a good reason for doing it
> the other way from the programmer's point of view, rather
> than for the convenience of the compiler.
You can't but Randy posted a very good explanation of why his compiler
does it in a different order. And even at the risk of sounding like a
broken record, the Ada standard say this will be done in "an arbitrary
order." If a user wants to, he can use other language rules (and code
that makes it obvious that it is intentional) to force a particular
evaluation order. But it is much harder to do that than to make the
code agnostic about evaluation order, and that is intentional.
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread* Re: In-Out Parameters for functions
2004-02-26 13:50 ` Robert I. Eachus
@ 2004-02-26 16:00 ` Hyman Rosen
2004-02-28 17:48 ` Robert I. Eachus
2004-02-27 6:00 ` Stephen Leake
1 sibling, 1 reply; 203+ messages in thread
From: Hyman Rosen @ 2004-02-26 16:00 UTC (permalink / raw)
Robert I. Eachus wrote:
> Randy posted a very good explanation of why his compiler
> does it in a different order.
Yes. That was finally a legitimate example of the compiler
using this permission to generate better code.
> But it is much harder to do that than to make the
> code agnostic about evaluation order, and that is intentional.
But unlike such things as array index violations, Ada isn't
required to tell you that your code is not agnostic about
evaluation order, and therefore such violations can lurk
undetected.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 16:00 ` Hyman Rosen
@ 2004-02-28 17:48 ` Robert I. Eachus
0 siblings, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-28 17:48 UTC (permalink / raw)
Hyman Rosen wrote:
> But unlike such things as array index violations, Ada isn't
> required to tell you that your code is not agnostic about
> evaluation order, and therefore such violations can lurk
> undetected.
No matter how hard we try, it is not always possible for a compiler to
read the programmer's mind. So there will always be bugs that exist
only in the author's mind. If I write:
X := X + 10;
But I actually intended to decrement X, the compiler can't catch that.
In fact on some other day, I might write identical code and expect X to
be incremented. (In fact what probably happened was that I did a sloppy
cut-and-paste, but ignore that for now.)
Compilers can notice suspicious code, and warn the author. For example,
if I had written:
X := X + 0;
A good compiler might warn me that the assignment statement resulted in
no code being generated, and that might lead me to find MY bug. But
bugs are always a matter of definition. That is why I like the style of
programming where I start with a list of requirements, and the code is
expected to implement those requirements exactly. That way the judgment
of whether or not something is a bug is objective, not personal.
(Doesn't stop me from considering "poorly formatted output" to be a
valid bug report.)
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-26 13:50 ` Robert I. Eachus
2004-02-26 16:00 ` Hyman Rosen
@ 2004-02-27 6:00 ` Stephen Leake
2004-02-28 18:18 ` Robert I. Eachus
1 sibling, 1 reply; 203+ messages in thread
From: Stephen Leake @ 2004-02-27 6:00 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net> writes:
> You can't but Randy posted a very good explanation of why his compiler
> does it in a different order. And even at the risk of sounding like a
> broken record, the Ada standard say this will be done in "an arbitrary
> order."
Hymen is trying to discuss a change to that Ada rule. Repeating what
the current Ada rules say is not helpful.
> If a user wants to, he can use other language rules (and code that
> makes it obvious that it is intentional) to force a particular
> evaluation order. But it is much harder to do that than to make the
> code agnostic about evaluation order, and that is intentional.
Ok. Some of us don't understand why it is harder; that would be a
useful thing to talk about.
--
-- Stephe
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-27 6:00 ` Stephen Leake
@ 2004-02-28 18:18 ` Robert I. Eachus
0 siblings, 0 replies; 203+ messages in thread
From: Robert I. Eachus @ 2004-02-28 18:18 UTC (permalink / raw)
I said:
>>If a user wants to, he can use other language rules (and code that
>>makes it obvious that it is intentional) to force a particular
>>evaluation order. But it is much harder to do that than to make the
>>code agnostic about evaluation order, and that is intentional.
Stephen Leake wrote:
> Ok. Some of us don't understand why it is harder; that would be a
> useful thing to talk about.
I am probably not the best one to ask about it, since believe it or not,
one of my personal fights during the Ada 9X development process was
that it should be POSSIBLE to force an evaluation order.
But I'll give it a try. In modern CPUs synchronization calls that allow
"precise" interrupts are very expensive, in an execution time sense of
course. In Ada, this means that requiring variables to have specific
values when Constraint_Error is raised. Or for that matter when any
predefined exception is raised. But in practice the interesting cases
are for Constraint_Error.
If there is a specified order, then someone can write a test that raises
Constraint_Error in "interesting" places, and looks at the values of
variables in the handler. In Ada 83, there was a huge, nasty AI,
AI-315, that looked at this issue and RM 11.6 in general. (Notice that
section 11.6 Exceptions and Optimization in the Ada 83 manual
corresponds to 11.6 in Ada 95. This was very intentional.)
The debate over what to do about this "problem" in Ada 83 was never
resolved. In theory, the freedoms granted in (Ada 83) 11.6 could be
used to make almost any program do anything. But in practice there
were some very strict rules that made it almost impossible for compilers
to "take advantage" of these freedoms.
The tension was that the compiler vendors wanted to get rid of some of
the more onerous requirements. But those who wrote programs which
needed to raise (and handle) Constraint_Error were of course concerned
that Constraint_Error not turn into something where any attempt to
handle Constraint_Error could cause the hard drive to be overwritten.
The current solution as far as I am concerned goes a little too far in
the direction of allowing optimizations at the expense of making
exception handlers more difficult to write. In fact, you sometimes have
to insert a call to an independent subprogram just to guarantee the
necessary semantics. "An independent subprogram is one that is defined
outside the library unit containing the construct whose check failed,
and has no Inline pragma applied to it. Any assignment that occurred
outside of such abort-deferred operations or independent subprograms can
be disrupted by the raising of the exception, causing the object or its
parts to become abnormal, and certain subsequent uses of the object to
be erroneous, as explained in 13.9.1." (RM 11.6(6) where else?)
As far as programs that don't have to deal with Constraint_Error
handlers are concerned though, the situation is much better. If you
split a complex expression into a series of assignment statements, the
order of evaluation is not guaranteed, but you do get "as if" semantics.
(Again, absent Constraint_Error being raised.)
--
Robert I. Eachus
"The only thing necessary for the triumph of evil is for good men to do
nothing." --Edmund Burke
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-24 1:55 ` Hyman Rosen
2004-02-24 2:16 ` David Starner
@ 2004-02-24 8:22 ` Jacob Sparre Andersen
2004-02-24 9:31 ` Jean-Pierre Rosen
1 sibling, 1 reply; 203+ messages in thread
From: Jacob Sparre Andersen @ 2004-02-24 8:22 UTC (permalink / raw)
Hyman Rosen wrote:
> Where does Ada permit the concurrent execution of multiple function
> calls of an expression?
Nowhere (I can remember) - except that "arbitrary order" in my eyes
includes "at the same time".
> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
> a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
> abfg abgf afbg bafg bagf bgaf
Since Ada specifically is targeted to concurrent processing I find
that astonishment a bit strange. But maybe those people you're
thinking of aren't used to concurrent processing?
> > XY := doublet'(x => a+b, y => c+d);
> > If they are truly unconnected objects then perhaps they
> > should be processed in separate tasks.
>
> I will leave it to the people who describe Ada code as readeable to
> tell me whether turning a sequence of assignments into an aggregate
> or a pair of tasks is a good idea.
If the objects are _logically_ unconnected, the above notation implies
a connection between the objects that only exists for the sake of this
specific implementation. That may confuse later maintainers of the
code.
Jacob
--
"Banning open source would have immediate, broad, and
strongly negative impacts on the ability of many sensitive
and security-focused DOD groups to protect themselves
against cyberattacks" -- Mitre Corp.
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-24 8:22 ` Jacob Sparre Andersen
@ 2004-02-24 9:31 ` Jean-Pierre Rosen
0 siblings, 0 replies; 203+ messages in thread
From: Jean-Pierre Rosen @ 2004-02-24 9:31 UTC (permalink / raw)
From: "Jacob Sparre Andersen" <sparre@nbi.dk>
> Hyman Rosen wrote:
>
> > Where does Ada permit the concurrent execution of multiple function
> > calls of an expression?
>
> Nowhere (I can remember) - except that "arbitrary order" in my eyes
> includes "at the same time".
Definitely not. 1.1.4 (18):
Whenever the run-time semantics defines certain actions to happen in an arbitrary order, this means that
the implementation shall arrange for these actions to occur in a way that is equivalent to some sequential order,
following the rules that result from that sequential order.
Otherwise it would mean that all functions should protect themselves against concurrent evaluation, even if there are not tasks in
the program!
Of course, if a compiler determines that a function has no side effect, it can do concurrent evaluation under the "as if" rule. Note
that the rule really says that "it shall be equivalent to some sequential order", not that it is evaluated sequentially.
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 203+ messages in thread
* Re: In-Out Parameters for functions
2004-02-03 14:06 ` Hyman Rosen
2004-02-03 15:32 ` Dmitry A. Kazakov
@ 2004-02-04 3:01 ` Alexandre E. Kopilovitch
2004-02-04 3:26 ` Ludovic Brenta
1 sibling, 1 reply; 203+ messages in thread
From: Alexandre E. Kopilovitch @ 2004-02-04 3:01 UTC (permalink / raw)
To: comp.lang.ada
Hyman Rosen wrote:
> > + is commutative
>
> Mathematics went beyond dogmatic statements like that many years ago.
Very interesting information. May I ask you for a couple of references? I mean
authoritative mathematical books where plus sign (+, without any modifications)
denotes some non-commutative operation.
And also, if the value of "pi" or "e" constant is somehow changed recently
(or if they are no longer constants) - in modern mathematics - then please
tell us that.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 203+ messages in thread