Ada-Comment proposals (version 3)

Ada-Comment proposals (version 3)

[Simon Clubley]

I've restructured issue 1 to turn it into a general partial aggregates
proposal. The atomic updating of device register bitfields discussion
is still pretty much the same but the additional comments and examples
from Niklas make it a more general proposal.

Niklas, since I have included your words and examples directly, can you
make sure you are happy with what I have included please ?

Issue 2 has had the question about 'Size added and some wording clarified.

I've posted this in it's own thread so any comments are clearly associated
with this version.

I think this is now ready for submission, so if there are no further
comments, I will submit it.

Simon.

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

!topic		Adding partial aggregate functionality to Ada
!reference	Ada 2012 RM{clause unsure}
!from		Simon Clubley 2014-07-13
!keywords	partial aggregate device register bitfields atomic updating

[The original motivation for this proposal was the simultaneous
updating of multiple bitfields in a device register. However,
discussions in comp.lang.ada have revealed a wide range of potential
uses for this notation which would allow these other existing uses
to be expressed more cleanly. The examples demonstrating the wider
potential of this proposal were provided by Niklas Holsti.]

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

Normal (non-atomic) records also have similar issues.

For normal records, consider 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.

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

Proposal
--------
An elegant solution for these problems would be a new partial aggregate
syntax in which the list of record components to be modified would be
listed along with their new values.

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 for the keyword 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.]

For an Atomic record, the compiler would 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 and there would be a single
read of the device register and a single write to the device register.

For the normal record example above, one could simply write instead

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

which is much more elegant than the above methods currently provided
by Ada.

In addition, Niklas also provided the following array aggregate 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);

It was also suggested partial aggregates could be of use in contracts
within Ada 2012 and also had some uses within SPARK. However, this is
one area I currently have no experience with, so I reproduce the
following example as-is:

|I have not yet used Ada 2012 contracts in my programming, but I believe
|that partial aggregates would be quite useful in post-conditions, to
|express that some "out" value is the same as some "in" value except for
|changes to certain components:
|
|   with Post => X = (X'old changing Colour => Black)

Regarding the use of a new keyword, 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-13
!keywords	Atomic update record components

This submission was prompted by an issue identified recently in
comp.lang.ada. On an ARM target, a 32-bit record, with multiple bitfields,
was defined as Atomic. However, the generated code showed that when a
bitfield, instead of the record as a whole, was referenced, GNAT
sometimes used ldrb/strb (byte level access instructions) instead of
ldr/str (32 bit access instructions).

This broke the hardware requirement that the register this record was
been used to access must be accessed in units of 32 bits.

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 record to
be accessed in units of 32 bits or is the compiler permitted to
generate code to access, say, 8 bits of the record only ?

C.6(15) states:

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

There are conflicting opinions about the above rule 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 other options can be considered if it doesn't.

As a related question, when C.6(15) does apply, does it also apply to
all the bits included by 'Size when 'Size has been used to increase
the size of the atomic object (say from 5 bits to 32 bits) ?

Possible solutions:

If C.6(15) applies when accessing a single bitfield in an Atomic record,
then this is clearly a GNAT bug and needs handling as such.

If C.6(15) is deemed not to apply to a single bitfield, then we need a
mechanism to indicate, in the program source code, that the compiler is
not allowed to reference a bitfield in an Atomic record by just
accessing one segment of that record's memory.

If the partial aggregate proposal is approved, then this could be the
mechanism. If it is not approved, then a pragma/aspect along the lines
of "No_Segmented_Access" could be the mechanism to enforce this.

I do believe a mechanism is required in Ada itself however. The special
requirements of the register should be declared in the source code, for
the compiler (and maintainers) to see, so that it can be guaranteed to
be honoured when the code is compiled.

Thank you,

Simon.

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

Re: Ada-Comment proposals (version 3)

[Niklas Holsti]

On 14-07-13 19:54 , Simon Clubley wrote:
> I've restructured issue 1 to turn it into a general partial aggregates
> proposal. The atomic updating of device register bitfields discussion
> is still pretty much the same but the additional comments and examples
> from Niklas make it a more general proposal.
> 
> Niklas, since I have included your words and examples directly, can you
> make sure you are happy with what I have included please ?

Quite ok, thanks. I have just one additional comment:

> For an Atomic record, the compiler would generate a Read-Modify-Write
> sequence

I'm afraid that saying "Read-Modify-Write" may be misunderstood to mean
a fully atomic update, not just an atomic read followed by an atomic
write of a new value, where other accesses to the record variable can
occur between the read and the write. Wikipedia defines
"read-modify-write" as an atomic update, giving the "test-and-set"
instruction type as one example.

It would be safer to write something like this: "the compiler would
generate an atomic read of the whole record variable into a
compiler-created temporary (perhaps a register), followed by an update
of the temporary according to the component updates listed in the
partial aggregate, and ending by an atomic write of the whole updated
value into the record variable".

This brings to mind an interesting question: if the processor has some
fully atomic read-modify-write instructions, and the semantics of one of
these instructions matches the way the record variable is updated with a
partial aggregate, is the compiler allowed to use that read-modify-write
instruction? I don't know if such instructions always work with
memory-mapped peripheral registers -- for example, their timing in terms
of clocks between the read and the write may be different.

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

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-13, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-07-13 19:54 , Simon Clubley wrote:
>> I've restructured issue 1 to turn it into a general partial aggregates
>> proposal. The atomic updating of device register bitfields discussion
>> is still pretty much the same but the additional comments and examples
>> from Niklas make it a more general proposal.
>> 
>> Niklas, since I have included your words and examples directly, can you
>> make sure you are happy with what I have included please ?
>
> Quite ok, thanks. I have just one additional comment:
>
>> For an Atomic record, the compiler would generate a Read-Modify-Write
>> sequence
>
> I'm afraid that saying "Read-Modify-Write" may be misunderstood to mean
> a fully atomic update, not just an atomic read followed by an atomic
> write of a new value, where other accesses to the record variable can
> occur between the read and the write. Wikipedia defines
> "read-modify-write" as an atomic update, giving the "test-and-set"
> instruction type as one example.
>

This was one of the things which was discussed with Randy a few days
ago. At that time, it was made clear by Randy that Atomic, as applied
to Ada, only ever meant the read was atomic and the write was atomic.
The overall sequence itself is never considered to be an atomic
operation.

I'll see about tweaking the language to make that more clearer however.

> It would be safer to write something like this: "the compiler would
> generate an atomic read of the whole record variable into a
> compiler-created temporary (perhaps a register), followed by an update
> of the temporary according to the component updates listed in the
> partial aggregate, and ending by an atomic write of the whole updated
> value into the record variable".
>
> This brings to mind an interesting question: if the processor has some
> fully atomic read-modify-write instructions, and the semantics of one of
> these instructions matches the way the record variable is updated with a
> partial aggregate, is the compiler allowed to use that read-modify-write
> instruction? I don't know if such instructions always work with
> memory-mapped peripheral registers -- for example, their timing in terms
> of clocks between the read and the write may be different.
>

We would have to be _very_ careful here that we didn't introduce
behaviour which could be platform specific.

For example, we would not want people to write code which didn't
consider what happens during an interrupt simply because that wasn't
an issue on the original platform due to the generated code emitted
by the compiler.

And yes, I know that people should not be writing code which depends
on compiler behaviour. :-)

Simon.

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

Re: Ada-Comment proposals (version 3)

[Niklas Holsti]

On 14-07-13 21:16 , Simon Clubley wrote:
> On 2014-07-13, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-07-13 19:54 , Simon Clubley wrote:

>>> For an Atomic record, the compiler would generate a Read-Modify-Write
>>> sequence
>>
>> I'm afraid that saying "Read-Modify-Write" may be misunderstood to mean
>> a fully atomic update, ...
> 
> This was one of the things which was discussed with Randy a few days
> ago. At that time, it was made clear by Randy that Atomic, as applied
> to Ada, only ever meant the read was atomic and the write was atomic.
> The overall sequence itself is never considered to be an atomic
> operation.

Exactly, so it is not "read-modify-write" as Wikipedia defines this term
(and as I, too, understand it).

> I'll see about tweaking the language to make that more clearer however.

Good.

>> This brings to mind an interesting question: if the processor has some
>> fully atomic read-modify-write instructions, and the semantics of one of
>> these instructions matches the way the record variable is updated with a
>> partial aggregate, is the compiler allowed to use that read-modify-write
>> instruction? I don't know if such instructions always work with
>> memory-mapped peripheral registers -- for example, their timing in terms
>> of clocks between the read and the write may be different.
>>
> 
> We would have to be _very_ careful here that we didn't introduce
> behaviour which could be platform specific.

I should have been clearer in my comment -- I did not really mean that
this question should be added to this Ada-Comment, rather I meant to ask
if someone knows of examples of peripheral registers for which
read-modify-write instructions do not work.

> For example, we would not want people to write code which didn't
> consider what happens during an interrupt simply because that wasn't
> an issue on the original platform due to the generated code emitted
> by the compiler.

Does this mean that you want to forbid Ada compilers from using
read-modify-write instructions?

It is always possible to write platform-specific code, intentionally or
accidentally. In particular, the execution timing and therefore the
locations of preemptions and interrupts is platform specific. For
example, a shared but unprotected variable may work reliably on one
platform but fail due to race conditions on another. Therefore, I would
let the compiler use read-modify-write instructions if it wants to, and
as long as the ARM is obeyed. I don't see it as an important problem
that this would make the some updates fully atomic on some platforms,
while the same source code result in a non-atomic update on another
platform.

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

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-13, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-07-13 21:16 , Simon Clubley wrote:
>> On 2014-07-13, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>> This brings to mind an interesting question: if the processor has some
>>> fully atomic read-modify-write instructions, and the semantics of one of
>>> these instructions matches the way the record variable is updated with a
>>> partial aggregate, is the compiler allowed to use that read-modify-write
>>> instruction? I don't know if such instructions always work with
>>> memory-mapped peripheral registers -- for example, their timing in terms
>>> of clocks between the read and the write may be different.
>>>
>> 
>> We would have to be _very_ careful here that we didn't introduce
>> behaviour which could be platform specific.
>
> I should have been clearer in my comment -- I did not really mean that
> this question should be added to this Ada-Comment, rather I meant to ask
> if someone knows of examples of peripheral registers for which
> read-modify-write instructions do not work.
>

Don't worry. I didn't think you were suggesting such a thing. :-)

>> For example, we would not want people to write code which didn't
>> consider what happens during an interrupt simply because that wasn't
>> an issue on the original platform due to the generated code emitted
>> by the compiler.
>
> Does this mean that you want to forbid Ada compilers from using
> read-modify-write instructions?
>

To be honest, it was just an instinctive reaction which was more
stronger than intended.

Along with my preference for type safe languages, I also have a
dislike for code generators which save 0.01% of runtime by doing
some "clever" code generation trick and introduces platform specific
behaviour as a result.

I would be more tolerant of these things in Ada than in some other
languages because I assume the type of person who uses Ada would
be disciplined enough to write code which doesn't depend on specific
compiler code generation behaviour.

Even then, such a person can be caught out as the current ldr/ldrb
and str/strb issues prove.

> It is always possible to write platform-specific code, intentionally or
> accidentally. In particular, the execution timing and therefore the
> locations of preemptions and interrupts is platform specific. For
> example, a shared but unprotected variable may work reliably on one
> platform but fail due to race conditions on another.

It can even succeed or fail on the same platform, depending on whether,
for example, you have instruction and/or data caching turned on.

> Therefore, I would
> let the compiler use read-modify-write instructions if it wants to, and
> as long as the ARM is obeyed. I don't see it as an important problem
> that this would make the some updates fully atomic on some platforms,
> while the same source code result in a non-atomic update on another
> platform.
>

For Ada, I'm going to agree with you after having thought about it.

Simon.

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

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

I've sent the final version to Ada-Comment. The only change over this
version was to alter the read-modify-write text as suggested by Niklas.

As requested by the Ada 2012 LRM, I sent it as two emails, one per
issue raised.

Thanks to everyone over the last few days who have provided feedback
and suggested changes.

I've included the final version below for reference.

Simon.

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

!topic		Adding partial aggregate functionality to Ada
!reference	Ada 2012 RM{clause unsure}
!from		Simon Clubley 2014-07-13
!keywords	partial aggregate device register bitfields atomic updating

[The original motivation for this proposal was the simultaneous
updating of multiple bitfields in a device register. However,
discussions in comp.lang.ada have revealed a wide range of potential
uses for this notation which would allow these other existing uses
to be expressed more cleanly. The examples demonstrating the wider
potential of this proposal were provided by Niklas Holsti.]

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

Normal (non-atomic) records also have similar issues.

For normal records, consider 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.

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

Proposal
--------
An elegant solution for these problems would be a new partial aggregate
syntax in which the list of record components to be modified would be
listed along with their new values.

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 for the keyword 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.]

For an Atomic record, the compiler would generate a sequence which
performs an atomic read of the whole record into a compiler generated
temporary, modifies this temporary with the new component values, then
performs an atomic write of this temporary back to the whole record.

As the sequence would be performed on the record as a whole, C.6(15)
would be guaranteed to apply. This means there would be a single read
of the device register and a single write to the device register.

For the normal record example above, one could simply write instead

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

which is much more elegant than the above methods currently provided
by Ada.

In addition, Niklas also provided the following array aggregate 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);

It was also suggested partial aggregates could be of use in contracts
within Ada 2012 and also had some uses within SPARK. However, this is
one area I currently have no experience with, so I reproduce the
following example as-is:

|I have not yet used Ada 2012 contracts in my programming, but I believe
|that partial aggregates would be quite useful in post-conditions, to
|express that some "out" value is the same as some "in" value except for
|changes to certain components:
|
|   with Post => X = (X'old changing Colour => Black)

Regarding the use of a new keyword, 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-13
!keywords	Atomic update record components

This submission was prompted by an issue identified recently in
comp.lang.ada. On an ARM target, a 32-bit record, with multiple bitfields,
was defined as Atomic. However, the generated code showed that when a
bitfield, instead of the record as a whole, was referenced, GNAT
sometimes used ldrb/strb (byte level access instructions) instead of
ldr/str (32 bit access instructions).

This broke the hardware requirement that the register this record was
been used to access must be accessed in units of 32 bits.

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 record to
be accessed in units of 32 bits or is the compiler permitted to
generate code to access, say, 8 bits of the record only ?

C.6(15) states:

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

There are conflicting opinions about the above rule 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 other options can be considered if it doesn't.

As a related question, when C.6(15) does apply, does it also apply to
all the bits included by 'Size when 'Size has been used to increase
the size of the atomic object (say from 5 bits to 32 bits) ?

Possible solutions:

If C.6(15) applies when accessing a single bitfield in an Atomic record,
then this is clearly a GNAT bug and needs handling as such.

If C.6(15) is deemed not to apply to a single bitfield, then we need a
mechanism to indicate, in the program source code, that the compiler is
not allowed to reference a bitfield in an Atomic record by just
accessing one segment of that record's memory.

If the partial aggregate proposal is approved, then this could be the
mechanism. If it is not approved, then a pragma/aspect along the lines
of "No_Segmented_Access" could be the mechanism to enforce this.

I do believe a mechanism is required in Ada itself however. The special
requirements of the register should be declared in the source code, for
the compiler (and maintainers) to see, so that it can be guaranteed to
be honoured when the code is compiled.

Thank you,

Simon.


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

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-13, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> I've sent the final version to Ada-Comment. The only change over this
> version was to alter the read-modify-write text as suggested by Niklas.
>

I am a little unsure about the timescale for what happens next.

Looking at the status attributes for some existing Ada Issues/ACs, it
looks to be about a month or two between reception of an email and any
decisions about any possible further action at some point in the future.
Is that correct ?

> As requested by the Ada 2012 LRM, I sent it as two emails, one per
> issue raised.
>

It will be interesting to see how the issues raised in both emails have
been received. :-)

Simon.

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

Re: Ada-Comment proposals (version 3)

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lq3nt1$hd9$1@dont-email.me...
> On 2014-07-13, Simon Clubley 
> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> I've sent the final version to Ada-Comment. The only change over this
>> version was to alter the read-modify-write text as suggested by Niklas.
>>
>
> I am a little unsure about the timescale for what happens next.
>
> Looking at the status attributes for some existing Ada Issues/ACs, it
> looks to be about a month or two between reception of an email and any
> decisions about any possible further action at some point in the future.
> Is that correct ?

Well, the only deadline for processing incoming mail is the next meeting. 
And I've sometimes even missed that (although has usually happened when I 
had a lot going on, not true at the moment). The next meeting is in October.

Anyway, the next step is for the editor and chair to perform triage (putting 
threads that are either decided or have no hope into ACs where they usually 
stay forever). In this case, as these are Amendment ideas, it's almost 
certain that they'll be put into AI form.

The next step after that is to consider them at a meeting (we almost never 
take an action based only on e-mail, except at the very start). Since we're 
not formally working on a future Ada standard at the moment, Amendment ideas 
are considered only when we have extra time during a meeting, and thus 
whether or when they progress is somewhat random. (The October meeting is 
shorter than usual, so I'm not expecting much work on Amendments at that 
meeting.) It doesn't matter until we formally decide to make a revision or 
amendment to the Ada standard, and who knows when we'll decide to start on 
that.

>> As requested by the Ada 2012 LRM, I sent it as two emails, one per
>> issue raised.
>>
>
> It will be interesting to see how the issues raised in both emails have
> been received. :-)

Did you join the Ada-Comment list, so you can see any ensuing discussion. 
Tucker asked you a question this morning and hopefully you saw it. (I'm 
going to answer it myself, but the original author probably ought to respond 
as well.)

                                    Randy.

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-15, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lq3nt1$hd9$1@dont-email.me...
>> On 2014-07-13, Simon Clubley 
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> As requested by the Ada 2012 LRM, I sent it as two emails, one per
>>> issue raised.
>>>
>>
>> It will be interesting to see how the issues raised in both emails have
>> been received. :-)
>
> Did you join the Ada-Comment list, so you can see any ensuing discussion. 
> Tucker asked you a question this morning and hopefully you saw it. (I'm 
> going to answer it myself, but the original author probably ought to respond 
> as well.)
>

Dammit, Dammit, Dammit. :-(

No, I did not as I didn't even realise that participation was even an
option. The way it's worded in the LRM, it came across as an address
the general public sent comments to, the issue was then discussed in
private, and then at some undefined point in the future, some summary
of the discussion, either as an AI/AC, was then produced.

There was also _nothing_ on http://www.ada-auth.org/ais.html about
a public facing mailing list when I was looking at the existing AIs
before submission. If I had known, I would have joined before making
the submissions.

I've just spent 15 minutes looking on the www.ada-auth.org website and
the _only_ reference to a mailing list I have found is:

|The ACAA mailing list contains announcements from the ACAA (such as new tests)
|and discussion about Ada Conformity Testing. While primarily intended for Ada
|compiler implementors, it is open to the general public. To subscribe, send a
|message with the body text "Join ACAA" to listserv@ada-auth.org. 

which certainly doesn't sound like it.

Where can I find the joining instructions and I will join right away.
Also, are there any archives available ?

I'm new to this whole Ada-Comment thing. Sorry. :-(

Simon.

PS: There's clearly some information source which has this list subscribe
information and I clearly have not yet come across this information source.
I would appreciate being pointed to it, because there's probably other
useful information there as well. Thanks.

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

Re: Ada-Comment proposals (version 3)

[Adam Beneschan]

On Tuesday, July 15, 2014 4:15:06 PM UTC-7, Simon Clubley wrote:

> PS: There's clearly some information source which has this list subscribe
> information and I clearly have not yet come across this information source.
> I would appreciate being pointed to it, because there's probably other
> useful information there as well. Thanks.

Try sending an e-mail whose body is "help Ada-Comment" to listserv@ada-auth.org.  That should give you info on how to subscribe, as well as how to retrieve the messages you missed.

P.S. I don't know offhand where one who isn't on the list can find this information.  I'm on the list, and I got the above from the blurb that's appended to the bottom of list messages.

                             -- Adam

Re: Ada-Comment proposals (version 3)

[Adam Beneschan]

On Tuesday, July 15, 2014 4:39:28 PM UTC-7, I wrote:
> On Tuesday, July 15, 2014 4:15:06 PM UTC-7, Simon Clubley wrote:

> Try sending an e-mail whose body is "help Ada-Comment" to listserv@ada-auth.org.  That should give you info on how to subscribe, as well as how to retrieve the messages you missed.

OK, to join the list, send an e-mail whose body is "join Ada-Comment" to the above address.  

I actually had a bit of trouble finding it.  If I Google "subscribe ada-comment", there's one search result that tells you how to put comments in an Ada program, and a bunch of search results for comments on ADA compliance or something.  

                              -- Adam

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-15, Adam Beneschan <adambeneschan@gmail.com> wrote:
> On Tuesday, July 15, 2014 4:39:28 PM UTC-7, I wrote:
>> On Tuesday, July 15, 2014 4:15:06 PM UTC-7, Simon Clubley wrote:
>
>> Try sending an e-mail whose body is "help Ada-Comment" to listserv@ada-auth.org.  That should give you info on how to subscribe, as well as how to retrieve the messages you missed.
>
> OK, to join the list, send an e-mail whose body is "join
> Ada-Comment" to the above address.
>

Thank you Adam.

Email sent, but no reply yet to either the join or the help command.

I'll pick this up again tomorrow evening. (Ada is not a work related
language for me.)

Thanks once again,

Simon.

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

Re: Ada-Comment proposals (version 3)

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:81096000-213d-461b-b50a-03357c84833d@googlegroups.com...
> On Tuesday, July 15, 2014 4:39:28 PM UTC-7, I wrote:
>> On Tuesday, July 15, 2014 4:15:06 PM UTC-7, Simon Clubley wrote:
> I actually had a bit of trouble finding it.  If I Google "subscribe 
> ada-comment", there's
>one search result that tells you how to put comments in an Ada program, and 
>a bunch
>of search results for comments on ADA compliance or something.

You should have tried the "all Ada search engine" rather than one of those 
giants. It only indexes sites with known Ada content. And it's written (both 
the crawler and engine) our favorite programming language. :-) Find it at 
htttp://www.adaic.org/ada-resources/ada-on-the-web/.

(Of course, having done that, it got a lot of irrelevant results as well. 
Sigh. I finally found the right page by looking for "join  ada-comment", 
with the quotes.)

The Ada-Comment page used to be prominently featured on AdaIC, but it got 
shuffled back when the site was reorganized. It's now found at: 
http://www.adaic.org/resources/add_content/standards/articles/comment.html. 
I know it's linked from various places, but I admit that I couldn't find one 
when I looked.

                              Randy.

Re: Ada-Comment proposals (version 3)

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> The Ada-Comment page used to be prominently featured on AdaIC, but it
> got shuffled back when the site was reorganized. It's now found at:
> http://www.adaic.org/resources/add_content/standards/articles/comment.html.
> I know it's linked from various places, but I admit that I couldn't
> find one when I looked.

The title of that page is "SHA-1 Checksums"!!!

Re: Ada-Comment proposals (version 3)

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lybnsis6tf.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> The Ada-Comment page used to be prominently featured on AdaIC, but it
>> got shuffled back when the site was reorganized. It's now found at:
>> http://www.adaic.org/resources/add_content/standards/articles/comment.html.
>> I know it's linked from various places, but I admit that I couldn't
>> find one when I looked.
>
> The title of that page is "SHA-1 Checksums"!!!

Close enough, right? :-)

I decided to copy that page into http://www.ada-auth.org/ais.html, so it 
won't be used anymore. Which is good, because I don't remember how to fix it 
(it's some weird Unix program; it's outside of Wordpress).

                             Randy.

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-15, Adam Beneschan <adambeneschan@gmail.com> wrote:
> On Tuesday, July 15, 2014 4:15:06 PM UTC-7, Simon Clubley wrote:
>
>> PS: There's clearly some information source which has this list subscribe
>> information and I clearly have not yet come across this information source.
>> I would appreciate being pointed to it, because there's probably other
>> useful information there as well. Thanks.
>
> Try sending an e-mail whose body is "help Ada-Comment" to
> listserv@ada-auth.org.  That should give you info on how to subscribe,
> as well as how to retrieve the messages you missed.
>

Thank you. I'm doing that now.

Given the current time here in the UK, any replies are probably going
to have to wait until tomorrow evening however.

> P.S. I don't know offhand where one who isn't on the list can find
> this information.  I'm on the list, and I got the above from the blurb
> that's appended to the bottom of list messages.
>

If this information isn't documented in some high profile place I have
missed, then it needs to be. The obvious place is the overall index
page for the AI/AC documents.

Simon.

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

Re: Ada-Comment proposals (version 3)

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lq4etk$o8r$1@dont-email.me...
...
> If this information isn't documented in some high profile place I have
> missed, then it needs to be.

It's documented in a "high-profile place" - AdaIC - 
http://www.adaic.org/resources/add_content/standards/articles/comment.html,
but I admit I couldn't find where it is linked from.

> The obvious place is the overall index page for the AI/AC documents.

Humm, it wasn't obvious to me until you mentioned it. :-) It's done now.

                            Randy.



                           Randy.

Re: Ada-Comment proposals (version 3)

[Simon Clubley]

On 2014-07-21, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lq4etk$o8r$1@dont-email.me...
> ...
>> If this information isn't documented in some high profile place I have
>> missed, then it needs to be.
>
> It's documented in a "high-profile place" - AdaIC - 
> http://www.adaic.org/resources/add_content/standards/articles/comment.html,
> but I admit I couldn't find where it is linked from.
>
>> The obvious place is the overall index page for the AI/AC documents.
>
> Humm, it wasn't obvious to me until you mentioned it. :-) It's done now.
>

I've looked at the text on http://www.ada-auth.org/ais.html and it
contains all the information about the nature of Ada-Comment and
joining it which I would need if I encountered Ada-Comment for the
first time.

Two minor typo notes:

The last sentence of the first paragraph "(To submit a comment, use the
Ada-Comment list as described in the Ada Standard, or see below." does
not have a closing bracket.

In the last sentence on the page the word "help" in "help ada-comment"
is not bolded.

Simon.

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

Re: Ada-Comment proposals (version 3)

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lqk6ee$l1p$3@dont-email.me...
> On 2014-07-21, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> message news:lq4etk$o8r$1@dont-email.me...
>> ...
>>> If this information isn't documented in some high profile place I have
>>> missed, then it needs to be.
>>
>> It's documented in a "high-profile place" - AdaIC -
>> http://www.adaic.org/resources/add_content/standards/articles/comment.html,
>> but I admit I couldn't find where it is linked from.
>>
>>> The obvious place is the overall index page for the AI/AC documents.
>>
>> Humm, it wasn't obvious to me until you mentioned it. :-) It's done now.
>>
>
> I've looked at the text on http://www.ada-auth.org/ais.html and it
> contains all the information about the nature of Ada-Comment and
> joining it which I would need if I encountered Ada-Comment for the
> first time.
>
> Two minor typo notes:
>
> The last sentence of the first paragraph "(To submit a comment, use the
> Ada-Comment list as described in the Ada Standard, or see below." does
> not have a closing bracket.
>
> In the last sentence on the page the word "help" in "help ada-comment"
> is not bolded.

Thanks for noticing the bugs. I should have proof-read it a third time (I 
think I was more worried that the links work). They're fixed now.

                        Randy.