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

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <4ivnr9$86o@dayuc.dayton.saic.com> John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:

  > Horrors! This assumes that Standard.Integer subsumes all possible ranges
  > of 'Pos values for all discrete types (enumeration, integer, modular).
  > A very dubious assumption!  What about Long_Long_Integer?  The long-term
  > reusability of this package is problematic.

    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.  (The
magic conversions implicit in 'POS and 'VAL in the body mean that
there is no risk of type mismatch.)

  > 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.

  > Finally, you're looking too narrowly at the problem:  You seem to be
  > focussed exclusively on analogs for ++ -- += -= , and are neglecting 
  > similarly contentious operations such as *= /= %= .  Also, you're
  > only looking at discrete types.  What about real types?  My inanely
  > trivial packages covered all the bases.

   I've never used *= /= or %= except when debugging a C compiler.

   As for real types, yes, if you feel those types are needed you do
need added packages.

  > However, your Cycle operation is a nice touch.

   Thanks.  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.

   
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...