Re: status of Ada STL?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> 18k11tm001@sneakemail.com (Russ) writes:
>  
> >By the way, it's too bad that Ada wasted "/=" on "not equals. It would
> >be very useful for dividing a matrix by a scalar. For example, the
> >construct
> >
> >A := A / 2.0;
> >
> >is very inefficient because a temporary matrix must be created to
> >store A/2, then an assignment must be used to put the result back in
> >A. On the other hand,
> >the construct
> >
> >A /= 2.0
> >
> >is not only much cleaner looking, it is much more efficient because
> >you can skip the temporary matrix and the assignment. And please don't
> >argue with me here, because you will only be showing your ignorance.
>  
> 
> Okay, I'll show my ignorance.  Let's say that your hypothetical Ada 0Y 
> compiler generated code without temporaries for the matrix operation A 
> /= 2.0;  Would it do the same for A /= 0.2?  If it did, what would 
> happen if one element resulted in an overflow?
> 
> On the other hand, if you choose to have the compiler use non-signalling 
> infinities for such overflows, then it is easy enough for the compiler 
> to do the inlining for all matrix op scalar combinations.
> 
> So as I see it, the issue here is not syntax, it is the Ada rule that an 
> exception on the right hand side of an assignment statement does not 
> destroy the target of the assignment.

That was true in Ada 83, but the rules in Ada 95 are much more lax.
As I read 11.6(6), if you have this:

    X := Matrix_Multiply(Y, Z);

if some operation inside Matrix_Multiply overflows, then X can indeed be
destroyed.  In RM terms, X can become "abnormal", which means merely
looking at it can cause you to turn into stone.

In fact, if you say:

    A := 1.0;
    X := Matrix_Multiply(Y, Z);
    B := 2.0;

then A and B can be destroyed, too.

11.6 is very subtle, and I'm not sure I fully understand it, and I'm
sure I don't like it.  ;-)  I think the moral of the 11.6 story is,
"don't handle predefined exceptions".

The changes to 11.6 were deliberate.  The purpose was to allow more
optimizations, e.g. on some modern machines where exceptions don't
get noticed until long after they have occurred.

Turning "X := X + Y;" into "X +:= Y;" is still not a trivial
optimization, because you have to worry about the aliasing.

>...  If you are willing to dispense 
> with that, you don't have Ada.  If you are proposing to add a syntax 
> (such as Foo++;) for such operations, go ahead.  Most of us will be 
> content with Inc(Foo); for cases where exceptions are not an issue. 
> Personally, I do define Inc for modular types, and I even have some code 
> which defines both:
> 
> procedure Inc(X: in out Modular);
> 
> and
> 
> function Inc(X: in Modular) return Modular;
> 
> I should probably lose some sleep over the potential confusion to the 
> reader, but it has never bothered me. ;-)

Sounds perfectly reasonable.  I like the above.  But C programmers will
want:

  function Inc(X: in out Modular) return Modular;

which is evil in my opinion.  (And happens to be illegal in Ada.)

What I really want to be able to do is:

  procedure Inc(X: in out Root_Modular'Class);

which is of course impossible to write in Ada.

- Bob