[sv-ac] Mantis 1901 grammar of cycle_delay/cycle_delay_range

I am confused by a change made to the 1800-2009 spec for
cycle_delay_range originally proposed in Mantis 1901. The
change allowed for a constant_primary following "##".
However, this was NOT done for cycle_delay_range. I believe
they should be consistent.

Futhermore, the change makes it far more difficult to parse
the language, in a way that doesn't occur in any other
grammar places in the language. (Below)

For these reasons, I would prefer if this change was backed
out and the () was always required as in 1800-2005, as this
makes the grammar far, far easier to implement - but suspect
it's too late ;)

Thanks.

Both 1800-2009 and 1800-2005:

  cycle_delay ::=
        '##' integral_number
        | '##' identifier
        | '##' '(' expression ')'

1800-2005:

  cycle_delay_range ::=
        '##' integral_number
        | '##' identifier
        | '##' '(' constant_expression ')'
        | '##' '[' cycle_delay_const_range_expression ']'

1800-2009:

  cycle_delay_range ::=
        '##' constant_primary
        | '##' '[' cycle_delay_const_range_expression ']'
        | '##[*]'
        | '##[+]'

The problem is

  sequence_expr ::=
        cycle_delay_range sequence_expr { cycle_delay_range sequence_expr }
        ...

  expands to
        '##' constant_primary sequence_expr
        ...

This is the only place in the entire language grammar where
a primary is next to an expression without a operator or
other token in between; this makes a mess, for example
constant_primary includes constant_function_call which
eventually includes

        system_tf_identifier [ '(' list_of_arguments ')' ]

where list_of_arguments can be empty

so we have

        '##' system_tf_identifier [ '(' [expr] ')' ] sequence_expr

and sequence_expr can contain a parenthesized expression
also, so we have a conflict - does the parenthesis belong to
the sequence or the identifier?

Having "primary(_constant) (sequence_)expr" adjacent makes
it impossible to parse as LALR - without top-down parsing
and retry; an implementation restriction not currently in
the language. (Or at least, I did 1800-2005 and am almost
done all of 1800-2009 except this, without it.)

Not to mention making it nearly impossible for humans to
read...

Thanks

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.