Re: Comments requested for a couple of Ada-Comments submissions

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-07-11 07:16 , Randy Brukardt wrote:
> "Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
> news:lpnb74$kmi$1@dont-email.me...
> ...
>> I don't see that there is anything here that the ARG would want to take 
>> action on, especially given that Randy said they're only interested in 
>> things that are hard or impossible to do in Ada. This is clearly not hard 
>> or impossible.
> 
> Well, actually, I understand that a similar problem came up recently (I 
> think it was related to SPARK) and that the GNAT people had already hacked 
> an ugly solution to it. A language-based solution would be better, at least 
> if it's not too expensive to implement.
> 
> After all, two independent problems that can be solved with a relatively 
> simple new feature make that feature more compelling. In any case, it's 
> certainly OK for Simon to submit the problem; I've seen a lot sillier ideas 
> than this one.
> 
>                                    Randy.

Thanks, Simon, for working up this proposal.

I think that this proposal should not be limited to solving the "update
of atomic" problem. The ability to write an aggregate that generates a
composite value by giving new values for just some of the components of
an existing composite value is quite useful in any context where a
composite value is used.

Such expressions are a mainstay of functional programming, which I feel
that Ada should support as a programming style, even if Ada is not a
pure functional language.

For example, given a record type Rec with many components, one of which
is Colour, a variable R of type Rec, and the need to call procedure Foo
twice, once using R with its own Colour, and once with R but using the
Black colour, we could do:

   Foo (R);
   Foo ((R changing Colour => Black));

There are two ways to do this in current Ada, but both are ugly. The
first uses a temporary variable, a copy, and an assignment to the component:

   declare
      T : Rec := R;
   begin
      Foo (R);
      T.Colour := Black;
      Foo (T);
   end;

The other way uses an aggregate listing all components of Rec, which is
very cumbersome and a burden for maintenance:

   Foo (R);
   Foo ((X => R.X, Y => R.Y, ...., Colour => Black));

Furthermore, the proposal should IMO not be limited to record types. The
same should be possible for array aggregates, as in this example:

   type Month_Days is array (Month) of Positive;

   Normal_Year_Days : constant Month_Days :=
      (Jan => 31, Feb => 28, Mar => 31, ..., Dec => 31);

   Leap_Year_Days : constant Month_Days :=
      (Normal_Year_Days changing Feb => 29);

As for the choice of keyword, while I agree that the best reading flow
needs a new keyword, I think that some existing keywords would be
tolerable, for example "overriding" as already suggested. Or how about
"new":

  (R new Colour => Black)
  (Normal_Year_Days new Feb => 28)

If we want a new keyword, I would suggest something short and almost
meaningless in itself, and therefore less likely to be used as an
identifier. For example "but":

   (R but Colour => Black)
   (Normal_Year_Days but Feb => 28)

Of course, there may be some French Ada programs using "But" as an
identifier, meaning "goal".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .