[vhdl-200x-ft] FT14: ambiguity in grammar for constraints

Folks,

On closer inspection of the proposed grammar, there is a possible ambiguity.

First, let's try to clarify the grammar for record constraints. The
proposal includes the rules

  record_element_constraint ::= identifier ( constraint )

  record_constraint ::=
    ( record_element_constraint { , record_element_constraint } )

However, a subsequent example includes the declarations

  type SIGNED_FXPT is array (INTEGER range <>) of BIT;
  type COMPLEX is
    record
      re : SIGNED_FXPT;
      im : SIGNED_FXPT;
    end record;
  type COMPLEX_2DIM is array (NATURAL range <>, NATURAL range <>) of
COMPLEX;

and then includes the subtype indication

  COMPLEX_2DIM(open)(re(WIDTH-1 downto 0), im(WIDTH-1 downto 0))

Since the elements re and im are both unconstrained arrays, the constraint
within each record element constraint should be an index constraint, which
requires enclosing parens. So the subtype indication should be

  COMPLEX_2DIM(open)(re((WIDTH-1 downto 0)), im((WIDTH-1 downto 0)))

I suspect the extra level of parens was not intended; please correct me if
I'm wrong. I think the intended syntax can be achieved with the following
rule

  record_element_constraint ::= identifier constraint

However, this introduces ambiguity into the grammar that can only be
resolved with semantic analysis. Consider the following subtype indication

  T ( x(1 to 3), y(1 to 3) )

The constraint could be parsed as a record constraint, with elements x and y
each being constrained by the index constraint (1 to 3). Alternatively, it
could be parsed as an index constraint, with x(1 to 3) and y(1 to 3) being
subtype indications for the index ranges. I know this latter interpretation
is already illegal, since x(1 to 3) cannot be a discrete subtype indication.
This is an existing semantic rule limiting the legal syntax. However, with
the introduction of the proposed (corrected) record constraint rule, there
would also be a purely syntactic ambiguity to deal with. Resolution using
semantics would get incrementally more complicated.

Is that acceptable?

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106