Comments requested for a couple of Ada-Comments submissions

Comments requested for a couple of Ada-Comments submissions

[Simon Clubley]

Hello,

Since it's my first time sending anything to Ada-Comments, I was hoping
for feedback before I submit them. I'm looking for things like style,
content, unclear language, etc. Among other things, I don't want to
waste Randy's time if I've missed something obvious. :-)

The two issues are below and thanks for any feedback,

Simon.

-----------------------------------------------------------------------------
Issue 1: Partial Aggregate notation

!topic		Updating multiple record bitfields as an atomic operation
!reference	Ada 2012 RM{clause unsure}
!from		Simon Clubley 2014-07-10
!keywords	bitfields records device registers atomic updating

Ada can model the bitfields in a device register as a record type
containing those bitfields and can map an instance of that record
type to the address of that device register.

However, sometimes there is a requirement to be able to update a
subset of those bitfields as an atomic operation while preserving
the contents of the other bitfields in the record.

In Ada, the only way to do this (apart from C style bitmasks on a
integer variable) is to read the device register into a temporary
instance of the record type, modify the temporary variable and
write the temporary variable back to the device register.

This, to put it mildly, is ugly.

A far better approach would be a new partial aggregate syntax in which
the list of bitfields to be modified would be listed along with their
new values.

The compiler would then generate a Read-Modify-Write sequence and, as
the operation would be on the record as a whole, C.6(15) would be
guaranteed to apply when Atomic is used and there would be one single
read of the device register and a single write to the device register.

One suggested syntax would be:

	A := (A changing C => D, E => F);

or

	A := (A updating C => D, E => F);

where A is a record and C and E are record components. When this syntax
discussion took place in comp.lang.ada one suggestion was "overriding"
but I didn't like that because that keyword made it seem as if A was
the one doing the overriding, not the later C and E references.

I do think we need a new keyword because we are talking about adding
a subset update capability to Ada and that new usage should stand
out in any code.

Thanks,

Simon.

-----------------------------------------------------------------------------
Issue 2: Does Atomic apply to record components ?

!topic		Does Atomic on a record apply to it's components ?
!reference	Ada 2012 RMC.6(15)
!from		Simon Clubley 2014-07-10
!keywords	Atomic update record components

C.6(15) states:

For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.

Scenario:

Consider a 32 bit record marked as Atomic. This record consists of
multiple bitfields and is used to model the bitfields in a 32 bit
memory mapped device register. The hardware requires the device
register to be read from and written to in units of 32 bits.

Now consider the following statement:

	Device_Register.bitfield := 1;

When this specific bitfield in the record, say 4 bits wide, is written
to, does the Atomic attribute on the record require the register to
be accessed in units of 32 bits or is the compiler permitted to
generate code to access, say, 8 bits of the register only ?

There are conflicting opinions in comp.lang.ada. The words "as a whole"
in C.6(15) were used to justify the position that access to this single
bitfield is not required to be in units of the record size which on the
surface seemed reasonable.

However, other opinions are that C.6(15) does apply when accessing this
single bitfield.

Which opinion is correct ?

I would like C.6(15) to apply, but I am more interested in obtaining a
firm decision so that we actually know one way or another.

You should be aware that generated code posted in comp.lang.ada shows
that for a ARM target, ldrb/strb (ie: byte level access) was used instead
of ldr/str (ie: 32 bit level access) when the bitfield was within the
first 8 bits of the register. This broke the hardware requirement this
register be accessed in units of 32 bits.

Thank you,

Simon.
-----------------------------------------------------------------------------

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

[Jeffrey Carter]

On 07/10/2014 05:02 PM, Simon Clubley wrote:
>
> This, to put it mildly, is ugly.

It seems to me that Ada's way of doing this is the least ugly of most languages.

Turn_On : declare
    T : Register_Info := Register;
begin -- Turn_On
    T.On := True;
    Register := T;
end Turn_On;

Show me any commonly used language that is less ugly than that.

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.

Sometimes these devices have fields that have to have zero written to them, but 
might be non-zero when read. For those cases, Ada looks even better:

Turn_On : declare
    T : Register_Info := Register;
begin -- Turn_On
    Register := (On => True, Zork => T.Piffle, Elffip => T.Kroz, others => 0);
end Turn_On;

-- 
Jeff Carter
"Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!"
Monty Python's Flying Circus
53

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

[Randy Brukardt]

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

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

[Niklas Holsti]

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

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

[Dan'l Miller]

On Friday, July 11, 2014 11:04:31 AM UTC-5, Niklas Holsti wrote:
>    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);

The already existing keyword "others" looks more Ada-ish.  Plus, it foregoes the pain of introducing a new reserved keyword.

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

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

[Simon Clubley]

On 2014-07-11, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> 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.
>

You are welcome.

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

That is a very good point. I will add wording that makes it clear the
exact same syntax could be used for general updating of, say, records
in general.

It does raise another point, however. So far, I have only thought about
non-discriminated records due to my focus on device registers. Are
there any additional issues when discriminated records are involved ?

It's only occurred to me just now while typing up this response, but
I can't see how it could possibly make a difference, even with
variant records.

However, I just thought I would ask the question anyway. :-)

>
> 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);
>

I can see what you are saying here. Let me have a think about it. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

[Niklas Holsti]

On 14-07-11 23:02 , Simon Clubley wrote:
> On 2014-07-11, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> 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.
>>
> 
> That is a very good point. I will add wording that makes it clear the
> exact same syntax could be used for general updating of, say, records
> in general.
> 
> It does raise another point, however. So far, I have only thought about
> non-discriminated records due to my focus on device registers. Are
> there any additional issues when discriminated records are involved ?

It seems to me that the legality and semantics of a partial aggregate
are easily defined by treating the partial aggregate as a syntactic
abbrevation of the corresponding full aggregate, that is, as syntactic
sugar. This should work even if some of the components named in the
partial aggregate are discriminants.

The only additional dynamic semantics to be defined are the indivisible
read ("as a whole") of an atomic object and the single read of a
volatile object, as you already have written in your proposal.

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

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

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lpn9ic$acs$1@dont-email.me...
...
> There are conflicting opinions in comp.lang.ada. The words "as a whole"
> in C.6(15) were used to justify the position that access to this single
> bitfield is not required to be in units of the record size which on the
> surface seemed reasonable.
>
> However, other opinions are that C.6(15) does apply when accessing this
> single bitfield.
>
> Which opinion is correct ?

I suspect that we're going to end up confirming what compilers do, rather 
than what they ought to do. That's because of the possibility of breaking 
existing working code if one enforced additional legality rules.

Which means an interesting question is the actual problem. If you have a 
device that can *only* be accessed by a 32-bit operation, any other access 
is wrong and it would be best if the compiler would report such accesses. 
(When I asked about it, I was told that GNAT doesn't even make a warning.) 
Requiring the compiler to do something that simply will not work is not 
helpful to anyone and isn't very Ada-like.

One possibility (assuming that piece-meal updating has to be allowed) would 
be to have a Restriction that could be applied to an atomic object, such 
that only reads and updates as a whole would be allowed. Reads and updates 
of parts would then be rejected. (Of course, such a restriction would only 
have an effect on objects of composite types.)

I think you ought to add something on this line to your submission; the 
critical point (the problem, as always) is buried that the very end of your 
question. Here, the problem is that accessing a device register piecemeal 
does not work, and there should be a way in Ada to prevent such accesses. If 
the existing rules don't have that effect, then we need some mechanism to 
ensure proper access.

So, I'd suggest putting the problem first (as in an AI), the question about 
the existing rules second, and then (optionally) a possible solution if the 
existing behavior is confirmed.

                                          Randy.

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

[Simon Clubley]

On 2014-07-11, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> I think you ought to add something on this line to your submission; the 
> critical point (the problem, as always) is buried that the very end of your 
> question. Here, the problem is that accessing a device register piecemeal 
> does not work, and there should be a way in Ada to prevent such accesses. If 
> the existing rules don't have that effect, then we need some mechanism to 
> ensure proper access.
>
> So, I'd suggest putting the problem first (as in an AI), the question about 
> the existing rules second, and then (optionally) a possible solution if the 
> existing behavior is confirmed.
>

Thanks Randy.

I'll revise it this weekend and post an updated version for comments
before submission.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Comments requested for a couple of Ada-Comments submissions

[Shark8]

On 10-Jul-14 18:02, Simon Clubley wrote:
> -----------------------------------------------------------------------------
> Issue 1: Partial Aggregate notation
>
> !topic	Updating multiple record bitfields as an atomic operation
> !reference	Ada 2012 RM{clause unsure}
> !from		Simon Clubley 2014-07-10
> !keywords	bitfields records device registers atomic updating
>
> Ada can model the bitfields in a device register as a record type
> containing those bitfields and can map an instance of that record
> type to the address of that device register.
>
> A far better approach would be a new partial aggregate syntax in which
> the list of bitfields to be modified would be listed along with their
> new values.
>
> The compiler would then generate a Read-Modify-Write sequence and, as
> the operation would be on the record as a whole, C.6(15) would be
> guaranteed to apply when Atomic is used and there would be one single
> read of the device register and a single write to the device register.
>
> One suggested syntax would be:
>
> 	A := (A changing C => D, E => F);
>
> or
>
> 	A := (A updating C => D, E => F);
>
> where A is a record and C and E are record components. When this syntax
> discussion took place in comp.lang.ada one suggestion was "overriding"
> but I didn't like that because that keyword made it seem as if A was
> the one doing the overriding, not the later C and E references.
>
> I do think we need a new keyword because we are talking about adding
> a subset update capability to Ada and that new usage should stand
> out in any code.

I don't really like the new keyword idea.
One way to do this would be to perhaps have an aspect say, "Atomic_At" 
whose value would be a list of components to group for reads and writes:

Type Some_Register_1 is record
    f1 : Bits(1..4);
    f2 : Bits(1..4);
    f3 : Bits(1..8);
end record
with Atomic_At => (f1, f2) and (f3);

--or--
Type Some_Register_2 is Array(1..16) of Boolean
with Pack, Atomic_At => (1..4) and (5..8) and (9..16);

-- or, if the above suggestion is syntactically impossible to handle we 
could use ((Some_Register_1.f1, Some_Register_1.f2), 
(Some_Register_1.f3)) & (Some_Register_2(1..4), Some_Register_2(5..8), 
Some_Register_2(9..16)), respectively.


Just an idea.

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

[Adam Beneschan]

On Thursday, July 10, 2014 9:56:36 PM UTC-7, Shark8 wrote:

> > One suggested syntax would be:
> > 	A := (A changing C => D, E => F);
> > or
> > 	A := (A updating C => D, E => F);
> > where A is a record and C and E are record components.

> I don't really like the new keyword idea.

    A := (C => D, E => F, others => A.others);

???

                           -- Adam

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

[Niklas Holsti]

On 14-07-11 18:35 , Adam Beneschan wrote:
> On Thursday, July 10, 2014 9:56:36 PM UTC-7, Shark8 wrote:
> 
>>> One suggested syntax would be:
>>> 	A := (A changing C => D, E => F);
>>> or
>>> 	A := (A updating C => D, E => F);
>>> where A is a record and C and E are record components.
> 
>> I don't really like the new keyword idea.
> 
>     A := (C => D, E => F, others => A.others);

To me, this looks too much like a normal aggregate. Only at the end,
from the new form "A.others", do we see that it is a partial aggregate.

Also, the duplication of the word "others" is a bit ugly, and "A.others"
does not really mean anything by itself; its meaning depends on the
components listed before the "others" part. How about:

   (C => D, E => F, then others => A)

or

   (C => D, E => F, and others => A)

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

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

[Adam Beneschan]

On Friday, July 11, 2014 10:26:44 AM UTC-7, Niklas Holsti wrote:

> >     A := (C => D, E => F, others => A.others);

> To me, this looks too much like a normal aggregate. Only at the end,
> from the new form "A.others", do we see that it is a partial aggregate.

> Also, the duplication of the word "others" is a bit ugly, and "A.others"
> does not really mean anything by itself; its meaning depends on the
> components listed before the "others" part. How about:
> 
>    (C => D, E => F, then others => A)
> 
> or
> 
>    (C => D, E => F, and others => A)

Something like this would be clearer:

    (C => D, E => F, others from A)

Unfortunately "from" isn't a reserved word and is already used as a parameter name in many language-defined packages.

So now I'm looking at the reserved word list to see if there's a way to use existing reserved words to convey this concept in an English-like fashion.

    (C => D, E => F, others out of A)

    (C => D, E => F, use all others in A)

But those are the best I could come up with.  (OK, I'm not really serious here.  But I do see your point about A.others.)

                           -- Adam

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

[Simon Wright]

Adam Beneschan <adambeneschan@gmail.com> writes:

>     (C => D, E => F, use all others in A)

   (A with new C => D, E => F)

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

[Georg Bauhaus]

On 11.07.14 20:00, Simon Wright wrote:
> Adam Beneschan <adambeneschan@gmail.com> writes:
>
>>      (C => D, E => F, use all others in A)
>
>     (A with new C => D, E => F)
>

Won't this expression require too much look-ahead in order to tell
apart
- a newly allocated C for some positional component
- a new value D to be put for C?


2 more ¢s,

   A := A (<> with C => D, E => F);

or, standing on my head,

A := A (D for C, F for E, <> for others);

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

[Dmitry A. Kazakov]

On Fri, 11 Jul 2014 19:00:29 +0100, Simon Wright wrote:

> Adam Beneschan <adambeneschan@gmail.com> writes:
> 
>>     (C => D, E => F, use all others in A)
> 
>    (A with new C => D, E => F)

A'Update (C => D, E => F)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Niklas Holsti]

On 14-07-11 22:10 , Dmitry A. Kazakov wrote:
> On Fri, 11 Jul 2014 19:00:29 +0100, Simon Wright wrote:
> 
>> Adam Beneschan <adambeneschan@gmail.com> writes:
>>
>>>     (C => D, E => F, use all others in A)
>>
>>    (A with new C => D, E => F)
> 
> A'Update (C => D, E => F)

Is that an assignment to A, or an expression yielding a value without
altering A? If the former, I'm against it, because it would solve only
the "atomic update" problem and would not have other uses.

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

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

[Dmitry A. Kazakov]

On Fri, 11 Jul 2014 22:16:32 +0300, Niklas Holsti wrote:

> On 14-07-11 22:10 , Dmitry A. Kazakov wrote:
>> On Fri, 11 Jul 2014 19:00:29 +0100, Simon Wright wrote:
>> 
>>> Adam Beneschan <adambeneschan@gmail.com> writes:
>>>
>>>>     (C => D, E => F, use all others in A)
>>>
>>>    (A with new C => D, E => F)
>> 
>> A'Update (C => D, E => F)
> 
> Is that an assignment to A, or an expression yielding a value without
> altering A? If the former, I'm against it, because it would solve only
> the "atomic update" problem and would not have other uses.

Expression:

   X := Y'Update (C => D, E => F);

What about arrays?

   Text := Text'Update (1..3 => ' ');

Containers?

Maybe 'Replace or 'Substitute.

However, I don't see how this should resolve the problem of atomic
operations. It is not only atomic update it is, and more important, atomic
test and conditional update, atomic increment and decrement, atomic test
and conditional increment, atomic swap etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:61zr552fwaif$.1gzem1sdpvtac.dlg@40tude.net...
> On Fri, 11 Jul 2014 19:00:29 +0100, Simon Wright wrote:
>
>> Adam Beneschan <adambeneschan@gmail.com> writes:
>>
>>>     (C => D, E => F, use all others in A)
>>
>>    (A with new C => D, E => F)
>
> A'Update (C => D, E => F)

This is roughly what GNAT is doing, and I think this is horrible. An 
attribute is some sort of function, and it would never be possible to write 
a function that works like this. I don't want more magic in the language if 
we can help it. Moreover, this ought to have the semantics of an aggregate 
(vis-a-vis temporaries, build-in-place, and the like), and as such it ought 
to look like an aggregate.

                                 Randy.

Comments requested for a couple of Ada-Comments submissions

[Shark8]

On 11-Jul-14 15:24, Randy Brukardt wrote:
> This is roughly what GNAT is doing, and I think this is horrible. An
> attribute is some sort of function, and it would never be possible to write
> a function that works like this. I don't want more magic in the language if
> we can help it. Moreover, this ought to have the semantics of an aggregate
> (vis-a-vis temporaries, build-in-place, and the like), and as such it ought
> to look like an aggregate.

I agree -- I think this should not be an attribute, nor the addition of 
new keywords.

Perhaps something along the lines of Extension Aggregates [ref 4.3.2].
-- Reminder --

extension_aggregate ::=
     (ancestor_part with record_component_association_list)

ancestor_part ::= expression | subtype_mark

-- New Syntax --
partial_aggregate ::=
     (modified_part with all others => <>)

where modified_part denotes the portion being updated, in list/alternate 
form...
-- Given record a containing integer fields B, C, D:
A:= (B => 1, D => 2 with all others => <>);
-- Given bit-array A with indices 1..16:
A:= (1..4 => 1, 9..16 => 0 with all others => <>);

It obviously wouldn't work on a unconstrained array-type initialization, 
where the variable would try to get its constraints from the right-hand 
side, but considering the intended use I don't see why that would be a 
bad thing.
Just an idea.

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

[Simon Clubley]

On 2014-07-11, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-07-11 18:35 , Adam Beneschan wrote:
>> 
>>     A := (C => D, E => F, others => A.others);
>
> To me, this looks too much like a normal aggregate. Only at the end,
> from the new form "A.others", do we see that it is a partial aggregate.
>

There's another potential problem with the "A.others" syntax.

Unless the rules were defined carefully, or unless Randy and company
decide that record components are covered by Atomic, it could result
in a partial read of A instead of a full read, and we could be back
to the ldr/ldrb saga once again. :-)

> Also, the duplication of the word "others" is a bit ugly, and "A.others"
> does not really mean anything by itself; its meaning depends on the
> components listed before the "others" part. How about:
>
>    (C => D, E => F, then others => A)
>
> or
>
>    (C => D, E => F, and others => A)
>

"And" is far better than "then" here but I think something that says
up front (before the components) that this is a partial aggregate
would be even more readable.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world