On Jan 27, 2006, at 4:09 AM, Bertrand Meltz wrote:
> My gneral question is :
> - Is a compound instruction where an īllegal operation is present, but
> actually masked, legal itself?
I'm, afraid that is a bit too general. It doesn't actually have an
answer at that level. In particular, you'd have to define what you mean
by "compound instruction", and I think you'll find that you can't do it
other than by listing specific cases. The standard does tend to define
what happens in the specific cases. The two cases you listed as
examples are actually completely different, illustrating the problem.
In the end, you have to look at the specific cases. There don't turn
out to be that many though.
> where ( a > 0. ) b = SQRT( a)
>
> Compilers generally compute all the SQRT( a), then perform the
> assignment only where it should.
> Some compilers used to choke if some of the a´s are negative, because
> it would be performimg an illegal operation.
Then those compilers are nonconforming. I won't bother to drag out the
definition of WHERE because it is awfully long, but such masking is a
fundamental part of the definition of WHERE. The masked-out elements
are not evaluated. WHERE is a very specific case, not like any other -
don't try to generalize it.
"IF" is also like this, though people tend to more intuitively
understand that one. If the condition in an "IF" is false, the
conditional statement or block is not executed. Run-time errors in it
will not be triggered. The subject of compile-time detection of errors
is more subtle... I'd have to check the interps on that (and I'm not
even convinced they are 100% consistent). Things like whether the
compiler can refuse to compile constructs like
if(.false.) write (*,*) sqrt(-1.)
> Is there a general way of determining whether such a construct
> is not standard conforming?
I'm afraid there isn't even a general definition of what "such a
construct" would be
> - My particular case today :
...turns out to be completely different.
> n2(i) = MERGE( n1(i), n1(i-d1), ( i < d1+1 ) )
Lots of people have noted that MERGE, as it stands, is not usable for
this kind of purpose for exactly the reason you noted. The problem
here is that MERGE is *NOT* anything special. It is an intrinsic
function. It is therefore a function. The operation of procedures
(including functions) is, at the top level, described as first
evaluating the arguments and then executing the procedure. In
particular, the "evaluating the arguments" bit comes first. There is no
way for a procedure to decide that one of its arguments need not be
evaluated. There is no concept of an argument being "masked out".
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|