!standard F.3.1    (04)                               96-09-04  AI95-00153/00
!class binding interpretation 96-09-04
!status received 96-09-04
!priority Medium
!difficulty Medium
!subject Picture String Grammar or Composition Rules Need Tightening

!summary 96-09-04


!question 96-09-04


!recommendation 96-09-04


!wording 96-09-04


!discussion 96-09-04


!appendix 96-09-04

!section F.3.1(04)
!subject Picture String Grammar or Composition Rules Need Tightening
!reference RM95-F.3.1(4,5,7,27)
!reference RM95-F.3.1(40-46)
!from Dan Lehman 96-06-26
!reference 96-5615.a Dan Lehman 96-6-27>>
!discussion

The String "++++>" and like Strings with '>' unmatched by any '<' are
valid picture Strings based on the following production sequence:

  picture_string              ::=  ... | non_currency_picture_string
  non_currency_picture_string ::= all_sign_number {...}
  all_sign_number             ::= all_sign_fore   [...] [>]
  all_sign_fore               ::= sign_char { ...} sign_char {sign_char | ...}
  sign_char                   ::= + | - | <

which can generate "++++>".

There are no composition constraints (F.3.1:40-46) that make such a
String invalid; yet this isn't intended to be a valid picture String,
according to Ben Brosgol, Robert Dewar, & Ken Fussichen.  What to do?
(F.3.1:43 forbids the occurrence of '>' only from an RHS_sign, not in
general.)

One solution is for F.3.1(43) to be extended to conclude:

    " ..., then it has no RHS_sign or occurrence of '>'. "

        ----------------------------------------------

[CAUTION:  UNINFORMED MUSING FOLLOWS (-; ]

While the above amendment to the composition rules seems to work, I'm
struck by the fact that of all the expansions listed for the 4 types of
picture_string in F.3.1(4-7) (p.421), ONLY ONE lacks a concluding [RHS_sign]
--viz., the 4th expansion for F.3.1(7), non_currency_picture_string.

So perhaps the better solution would be to amend the picture String
syntactic rules as follows:

  remove "[>]" from F.3.1(27) all_sign_number yielding

    ::= all_sign_for [radix [all_sign_aft]]              --removed [>]

  add "[RHS_sign]" to the 4th line of F.3.1(7) non_currency_picture_string ...

    ::= | all_sign_number {direct_insertion} [RHS_sign]  --added [RHS_sign]

Now, all_sign_number expands to just the 3 sign_char values '+', '-', '<';
and by F.3.1(44) only one of these sign_char values can exist in a particular
picture String.  By F.3.1(43), if + or - is in all_sign_number, there can be
NO RHS_sign value, so adding [RHS_sign] to F.3.1(7) in these cases will have
no effect--i.p., no ill effect--; and removing the All_S_N's potential for
'>' (newly) would invalidate Strings in which some direct_insertion followed
the '>', such as "<<>_0", "<<<<>BB", & "<<<>/".  But is it ever expected
that All_S_N generate "<...>" here?

And by (42), if '<' is in all_sign_number, then '>' must also occur in the
picture String; by the changes above, this '>' would have to come from
the RHS_sign, and so no possibility of RHS_sign generating '+' or '-'
exists in the suggested amendment to the 4th expansion in F.3.1(7).

Respectively, F.3.1(4 & 5)'s final expansions are:

  All_S_N {direct_insertion} fixed_$_char {direct_insertion} [RHS_sign]
  All_S_N {direct_insertion} fixed_#_currency {direct_insertion} [RHS_sign]

What would be lost are picture Strings where some direct_insertion et seqq.
followed the currently allowed occurrence of '>' (from current F.3.1:27),
such as "<<<>BBB", "<<<>$-", or "<<.<<>#BB+>".
Again, is it ever expected that All_S_N generate "<...>" here?

If indeed it IS the case that the changes to the syntactic rules I've mused
over can be made without ill effect, then the simplest change is to put the
[RHS_sign] production at the end of the 4 lines for F.3.1(3) picture_string,
removing it from all of F.3.1(4-7).

ps:  Next up:  The Hidden Meaning of F.3.1(2)!

---Dan Lehman
-------------- *

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