Re: 'with'ing and 'use'ing

[Stuart Palin <stuart.palin@gecm.com>]

"Charles H. Sampson" wrote:

<snip>

>  Not really.  Here are his [M. Rosen] conclusions, quoted directly
>  from the paper [arguing in favour of the use clause]:

<snip>
 
>           Of course, like any other feature, the use clause can be
>      abused of... and I don't know of any feature, even in Ada,
>      where this is not true . But apart from pathological cases,
>      reasonable use of the use clause provides more information to
>      the reader, and should be recommended as the usual practice.

It seems to me that the points raised in the c.l.a thread
"choice of fixed point type" highlight an area where the "use" clause
can give rise to some concerns.

tmoran@bix.com wrote
> The code in question arose from testing around an "Ada
> surprise".  An execution error had been traced to where a
> programmer had written something like
>   Long_Float(N * Ada.Numerics.pi)   instead of
>   Long_Float(N) * Ada.Numerics.pi
> resulting in the use of (relatively imprecise) type Duration
> for the multiply instead of Long_Float.  Standard.Duration
> was of course (silently) visible, and there was no other
> fixed point type in this code, so the compiler did what the
> programmer said, but not what he wanted.

Although an explicit "use clause" was not part of the difficulty here,
it seems that bringing things into scope unnecessarily increases the
possibility of this type of anomaly; where what is said is not what is
wanted and the compiler does not report an error because it can
interpret what was said.

This type of "gotcha" is a legitimate concern.  Even so rigorous
abstention from the use clause only limits the risk, it does not
eliminate it (since the unintended behaviour might fall within the
bounds of those things that have been brought into scope by either
renaming or "use type").

In this example the difficulties of detecting the error by testing can
be recognized - the error would only be apparent if the values chosen
gave intermediate results that were significantly different from the
model numbers (and so introduced rounding errors).

Regards
--
Stuart Palin
BAE SYSTEMS Electronics Limited