Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan <John_Volan@ccmail.dayton.saic.com>]

In article <EACHUS.96Mar25144123@spectre.mitre.org> 
Robert I. Eachus, eachus@spectre.mitre.org writes:

>    I felt that the range of Integer is large enough for most uses.
>In general I expect this package to be used with 1) enumeration types
>2) character types 3) loop indexes and 4) string indexes.

Two points:

- (2) is just a special case of (1). I could see your procedures going
into something like the Discrete_Arithmetic package I described, but
then I think the package ought to be called Enumeration_Arithmetic, to
emphasize the intent that the actual Item type be an enumeration.
  
- (3) and (4) might be enumerated types, but when they're integer types,
they could be supported more simply and directly by the
Integer_Arithmetic package I described.  No need to mix things up by
tying everything to Standard.Integer.
  
>  > Also, why limit Increment/Decrement to Positive?  Why not allow any
>  > arbitrary integer?  The C analogs for these procedures, += and -=,
>  > carry no such limitation.
>
>   Shrug.  I guess I could be convinced to Integer, but Inc(X, -1)
>seems silly.

If the following is legal in Ada:

    X := X + (-1);
    
then why should we presume to stop a programmer from doing:

    Increase (X, By => -1);
    
no matter how silly (we think) it is? 
    
And why do you assume that the second parameter to this procedure would
always be a (small) integer _literal_?  Given that you clearly are
making that assumption, I can understand how it wouldn't really matter
to you what type the second parameter was, so Standard.Integer is as
good as anything.  But this is what I mean by your focus being too
narrow. Here's a (somewhat) realistic example that overturns your
assumption:

    -- assume these are all the same type:
    Vertical_Acceleration := Gravity; -- happens to be negative (downward)
    Vertical_Velocity := ... ; -- could begin positive but ends up negative
    Altitude := ... ;
    ...
    while Altitude > 0 loop
        ...
        -- using a fast, but admittedly non-Newtonian, approximation, and
        -- assuming 1 unit (whatever that is) elapsed time between updates:
        
        Increase (Vertical_Velocity, By => Vertical_Acceleration);
        Increase (Altitude, By => Vertical_Velocity);
        ...
    end loop;
    Put_Line (">>CRUNCH!<<"); -- :-)
    
the C equivalent being:

        Vertical_Velocity += Vertical_Acceleration;
        Altitude += Vertical_Velocity;
            
Perhaps the words "Increase" and "Decrease" carry too much of a
connotation of directionality.  Perhaps we need better identifiers than
these to convey the sense of what += and -= really do.  Anybody have
any suggestions?

But on second thought, why isn't the second parameter on the "+" and "-"
functions limited to Positive?  Doesn't "addition" carry a sense of
making a value "bigger" and "subtraction" carry a sense of making a
value "smaller"?  Yet, despite these connotations, does anybody have
any trouble with the fact that you can _add_ a negative number and
thereby generate a _smaller_ value, or _subtract_ a negative number and
thereby generate a _bigger_ value?  Or that you can add or subtract
zero and get the same value?  Does this make "+" and "-" harder to
understand and less "readable"?  Or have we all managed to internalize
all these ideas?  Well, if we can do that with "+" and "-", then what's
the problem with transferring that understanding to "Increase" and
"Decrease" (or whatever you want to call them)?  Especially if we
explain to new Ada students that "Increase" is related to "+" and
"Decrease" is related to "-", so keep in mind everything you learned in
junior-high algebra?

(By the same token, why isn't the second parameter on "*" and "/"
restricted to numbers greater than 1.0?  Isn't multiplication
supposed to "expand" a value while division "reduces" it?  But if
you apply a number between 0.0 and 1.0 (exclusive), the effects of
these operations are the exact reverse.  And, of course, multiplying
or dividing exactly by 1.0 has no effect.  But do these properties
reduce the understandability or readability of "*" and "/"?
"You may very well think so, but I could not possibly comment."
-- Daniel Urquhart :-)

[snip]
>I left out the Min and Max also, but I now think the two
>argument versions should go in, but the versions with array parameters
>complicate things too much.

Are we talking Ada83 here?  If you mean Ada95, why reinvent the wheel?
Aren't Item'Min and Item'Max adequate?  Or did you mean:

    function Minimum_Of (This, That : in Item) return Item
        renames Item'Min;
        
    function Maximum_Of (This, That : in Item) return Item
        renames Item'Max;

Or maybe you meant:

    procedure Minimize (This : in out Item; Against : in Item) is
    begin
        This := Item'Min (This, Against);
    end Minimize;
    
    procedure Maximize (This : in out Item; Against : in Item) is
    begin
        This := Item'Max (This, Against);
    end Maximize;
    
As for array versions, well, there's a lot you could put into an
Array_Arithmetic package, but let's not go overboard... :-)

...

Hmm, I just realized that I missed a couple of operators.  Maybe we
should also include:

    procedure Negate (This : in out Item) is
    begin
        This := -This;
    end Negate;
    
    procedure Absolve (This : in out Item) is
    begin
        This := abs This;
    end Absolve; -- :-)  Well, can you think of a better related verb?

Of course, there's no C analog for these, but they do fit the pattern
of avoiding an error-prone repetition of a long target variable name.
  
------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------