Version 1.4 of ais/ai-00153.txt

Unformatted version of ais/ai-00153.txt version 1.4
Other versions for file ais/ai-00153.txt

!standard F.3.1 (04-38)          99-04-01 AI95-00153/01
!standard F.3.1 (01)
!standard F.3.1 (43)
!class binding interpretation 96-09-04
!status ARG Approved (with changes) 8-0-2 99-03-25
!status work item 99-03-21
!status received 96-09-04
!priority Medium
!difficulty Medium
!subject Picture String Grammar or Composition Rules Need Tightening
!summary
Picture strings such as "++++>" are not well formed.
!question
The String "++++>" and like Strings with '>' unmatched by any '<' appear to be 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 ::= + | - | <
Is the picture string "++++>" well formed? [No.]
!recommendation
A '>' character can only appear in an all_sign_number if it contains '<' characters.
!wording
Extend F.3.1(43) to read:
If a picture String has '+' or '-' as fixed_LHS_sign, in a floating_LHS_sign, or in an all_sign_number, then it has no RHS_sign {or '>' character}.
!discussion
The problem is that the production for all_sign_number does not use the RHS_sign production, it contains the literal '>'. This is what comes of trying to fold the picture string grammar and composition constraints into as few words as possible. Some of the composition constraints could have been included in a context-free grammar but at the expense of making it much longer, and more difficult to read.
!appendix

!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
-------------- *

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

Questions? Ask the ACAA Technical Agent