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

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

In article <dewar.827181191@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

  > Direction_Type'Increment (Direction);

  > does not seem very inspiring

  > Direction := Direction + 1;

  > seems OK. Yes, I know you can find complex cases, but in well written
  > code, complex stuff is minimized anyway, and for example nearly all
  > increments in the GNAT source are of simple variables.

   Agreed.  Very much agreed.  At one time I thought that Ada 9X
should include user defined attributes, but it just isn't that useful
a feature.  As Robert Dewar points out above the second form is
usually both shorter and reads better.  When you do lots of increments
and decrements what you really want is:

    Inc(Direction);

    And the code for that is fairly trival.  I may accept John Volan's
challenge and post a proposed package tomorrow.  But I don't think it
needs to be standardized.   (The issue I want to think about overnight
is whether the generic formal should be "is range <>" or "is (<>)".

    I already know that I want to rewrite the package to:

    procedure Inc(Object: in out Formal_Type);
    procedure Inc(Object: in out Formal_Type; By: in Integer);
    function Inc(Value: in Formal_Type) return Formal_Type;
    function Inc(Value: in Formal_Type; By: in Integer) return Formal_Type;
    
    Since you want the one parameter forms to inline right.

    (Should the function form be named something other than Inc and
Dec?  Does the Ada domain specific knowledge that the parameters of
a function are not changed dominate here, or should it be named Next?)

--

					Robert I. Eachus

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