Re: Row pattern recognition

Hi Henson,

Just a trivial comment to 1.

> While going over the row pattern grammar I want to put on record why the
> empty pattern -- PATTERN (()) and the like -- is left unsupported, and why
> I think that is the right call for this series rather than an oversight.
> 
> Today it is simply a syntax error.  row_pattern_primary is either a
> variable (ColId) or a parenthesized group '(' row_pattern ')', and
> row_pattern has no empty production, so '()' never parses.  The standard's
> pattern syntax does allow an empty row pattern -- it matches the empty
> sequence, i.e. it produces an empty match -- so the question is whether we
> should grow the grammar, plus an NFA "empty" element, to accept it.
> 
> My claim is that we do not need to: every way an empty pattern can appear
> reduces to something we already handle, so a dedicated empty element in
> the executor would be dead weight.  There are two cases.
> 
> 
> 1. The empty pattern is the whole pattern: PATTERN (())
> 
> This pattern has zero pattern variables.  But DEFINE is mandatory (per
> ISO/IEC 19075-5, Table 18), an empty DEFINE list is rejected, and every
> DEFINE variable must appear in PATTERN -- otherwise we already error with
> "DEFINE variable \"%s\" is not used in PATTERN".  A pattern with no
> variables cannot satisfy any of that: there is nothing for DEFINE to
> define, yet DEFINE can be neither omitted nor left empty.  So an all-empty
> pattern is rejected by the existing rules, with no new check needed.

I think current behavior is correct from the standard's point of
view. As you explained, there's no way to accept "PATTERN (())" or
"PATTERN ()" according to the R020 syntax rule.

Note, however, "PATTERN ()" is possible in R010 because it allows to
omit the DEFINE clause itself.

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp