Version 1.1 of acs/ac-00310.txt

Unformatted version of acs/ac-00310.txt version 1.1
Other versions for file acs/ac-00310.txt

!standard 4.3.5(0)          18-12-14 AC95-00310/00
!class Amendment 18-12-03
!status received no action 18-12-03
!status received 18-11-02
!subject Mixing square and round brackets in a single aggregate
!summary
!appendix

From: Randy Brukardt
Sent: Friday, November 2, 2018  4:36 PM

Brad asked me some questions about the aggregate syntax, and while there is no
problem with his concern, I did start wondering about multi-dimensional array
aggregates.

4.3.3(6) says that a multi-dimensional aggregate is made up of nested
aggregates. We're now allowing either square or round brackets for array
aggregates (from AI12-0212-1, which I think we approved at the recent meeting,
didn't get that far in the minutes yet), but while they have to pair up, there
isn't any requirements on a single aggregate. So it seems that not only:
    ((1, 2), (3, 4), (5, 6))
and
    [[1, 2], [3, 4], [5, 6]]
are legal, but also
    ([1, 2], [3, 4], [5, 6])
and
    [(1, 2), (3, 4), (5, 6)]
and even
    [(1, 2), [3, 4], (5, 6)]
    ([1, 2], (3, 4), (5, 6))
    [[1, 2], (3, 4), [5, 6]]
    ((1, 2), [3, 4], (5, 6))
and several more like these.

It seems that we ought to at a minimum require all of the subaggregates to use
the same brackets, and probably to require the entire aggregate to use the same
brackets. (Note that the container aggregates, which are only one-dimensional,
don't have this issue.) Whatever rule would probably be best stated as an
English language syntax rule (trying to put that into the grammar would be
maddening.

Thoughts??

***************************************************************

From: Jeff Cousins
Sent: Friday, November 2, 2018  4:55 PM

My first thoughts are that that would be something for a style guide, not
enforced by the language.

***************************************************************

From: John Barnes
Sent: Friday, November 2, 2018  5:18 PM

The ability to mix brackets can be helpful in clarifying the structure. But I
feel strongly that all brackets at the same level should be the same in the case
of nested aggregates.

If we were starting from scratch we might insist that brackets at adjacent
levels  had to be different to aid clarity. Too Late!

***************************************************************

From: Tucker Taft
Sent: Friday, November 2, 2018  5:24 PM

I don't think it is essential, but I could support it.  This seems purely a
project-specific kind of rule, sort of like requiring "in" to be explicit or
implicit depending on context.

***************************************************************

From: Bob Duff
Sent: Sunday, November 4, 2018  6:17 AM

> It seems that we ought to at a minimum require all of the
> subaggregates to use the same brackets, ...

That seems like good style, but I don't think it's worth the trouble to put in
the RM, even if everybody agreed on the exact rule.  They don't:

>... and probably to require the entire aggregate to use  the same
>brackets.

I don't see why outer and inner levels should match.
In maths, they commonly don't, for readability.

Also, I don't see why multi-dim arrays should be different from array-of-array.

I'd prefer not to argue about these details.
There are lots of similar stylistic issues that we don't bother about in the RM.
For example, I would never write:

    X : Integer := ((1));

but I don't feel a need to say so in the RM.
(Maybe in a different language.)

***************************************************************

From: John Barnes
Sent: Sunday, November 4, 2018  8:37 AM

But we cannot leave it all to a style guide since we could not tolerate an
aggregate with different opening and closing bracket such  as

Nasty: arraytype := (1, 2, 3];

If Ada 2020 allows that then I will vote against.

***************************************************************

From: Jeff Cousins
Sent: Sunday, November 4, 2018  8:59 AM

Left and right should match seems reasonable and presumably not too hard to
check, but I wouldn't go any further.

***************************************************************

From: Brad Moore
Sent: Sunday, November 4, 2018  10:47 AM

The syntax as currently defined requires left and right to match, so we have
that already.

eg.

  positional_array_aggregate ::=
      (expression, expression {, expression})
    | (expression {, expression}, others => expression)
    | (expression {, expression}, others => <>)
    | [ expression{, expression}[, others => expression] ]
    | [ expression{, expression}, others => <> ]
    | [ ]

Replace 4.3.3(4/5) with:
   named_array_aggregate ::=
      (array_component_association_list)
    | [array_component_association_list]

***************************************************************

From: John Barnes
Sent: Sunday, November 4, 2018  10:56 AM

Good

***************************************************************

From: Bob Duff
Sent: Sunday, November 4, 2018  1:05 PM

> But we cannot leave it all to a style guide since we could not
> tolerate an aggregate with different opening and closing bracket such
> as
>
> Nasty: arraytype := (1, 2, 3];

Well, that's a syntax error.

> If Ada 2020 allows that then I will vote against.

As well you should.  ;-)

***************************************************************

From: Tucker Taft
Sent: Sunday, November 4, 2018  6:46 PM

> Nasty: arraytype := (1, 2, 3];
>
> If Ada 2020 allows that then I will vote against.

The proposed syntax rules prevent such mongrels.

***************************************************************

From: John Barnes
Sent: Sunday, November 11, 2018  11:02 AM

> Good

That's odd. I sent that message ages ago.  Anyway, topic done I think.

***************************************************************

From: Randy Brukardt
Sent: Monday, November 12, 2018  1:41 PM

Really short messages, like one word answers, usually get delayed by the spam
filter and/or the moderation mechanism. (They rarely convey useful information,
and often are used to send links to malware or other garbage.) So they don't get
posted until I see them, and I was away a few days.

***************************************************************


Questions? Ask the ACAA Technical Agent