RE: gnubol: refmod again (fwd)

["William M. Klein" <wmklein@ix.netcom.com>]

I am new to the list - and to this thread, but a couple of comments that seem
relevant to this thread:

1) Commas are LEGAL (when followed by a space) WHEREVER a space is allowed
(except for one odd case at the end of a PICTURE string).  This means that

  Move, foo (index, +, 1, 2), to, whatever
     is perfectly legal (in '85 Standard COBOL) and is treated exactly as
  Move foo (index + 1 2) to whatever.

Therefore, giving ANY "real" syntactic meaning to commas is (and probably
always will be) impossible.

2) Using arithmetic expressions as subscripts is definitely in the next
Standard (and already allowed as an extension by many - but not all - COBOL
vendors).  The recent J4 discussion made it clear that you MUST include an
arithmetic expression that STARTS with a unary operator in parenthesis - when
used as a subscript.  Otherwise, you need not use them.  Thus,

   Elem (data-item + 1) *> uses a single arithmetic expression as a subscript
   Elem (data-item (+ 1)) *> uses a data-item and an arithmetic expression as
two subscripts
   Elem (data-item +1) *> uses a data-item and a signed integer (which is a
valid arithmetic expression) as two subscripts
   Elem (data-item (+1)) *> is semantically identical to the previous example

3) Can someone help me understand the comment,
  "If they're proposing general expressions in subscripts with no better
provision for them than you report, maybe it should be for large values of
X."
  What do you think is missing? There are rules for "subscript out of bounds"
(which are more explicit than those in the '85 Standard).

4) From the title of this "thread" (and not seeing what went before), did
this begin with a discussion of what to do if an arithmetic expression as the
start position or length of reference-modification doesn't evaluate to be an
integer?  If so, this is "explicitly" implementor defined.  I know that
*some* currently CONFORMING implementations round, others truncate, and still
others give run-time errors - all are "legal" as the definition of
"arithmetic expression" is totally implementor defined.

5) Concerning Randall's comment about parameters passed to functions versus
subscripts, I *think* that they are identical already in the draft Standard
(but I could be wrong) with the single exception (which is documented as
INCOMPATIBLE change from the '85 Standard) that you *must* use a set of
"empty parenthesis" to indicate "empty parameters" to a function which CAN
take zero or more arguments, i.e.

    You still have
        Move Function Current-Date to whatever
    but now have
        Compute num-field = Function Random ()
          or
        Compute Num-Field = Function Random (seed-value)

***

Does this answer any of the "real" outstanding questions, or should I have
stayed quiet until I "caught" up on what the real questions/issue are/were?

Bill Klein
  wmklein <at> ix.netcom.com

> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of Michael McKernan
> Sent: Wednesday, December 01, 1999 8:23 PM
> To: gnu-cobol@lusars.net
> Cc: mck@tivoli.mv.com
> Subject: Re: gnubol: refmod again (fwd)
>
>
> >>>>> "Randall" == Randall Bart <Barticus@att.net>
> >>>>> wrote the following on Wed, 01 Dec 1999 15:07:40 -0800
>
>   Randall> At 04:57 12/1/99 , J & C Migrations, Pty. wrote:
>   >> Hi Mike!  Both you and Randall seem to have missed this one:
>   >> (foo + 1) is a single index, (foo + 0 +1) is two indexes roughly
>   >> equivalent to (foo 1), and the original (foo + 0 + 1) is
>   >> illegal, because as you can see from the format you quoted
>   >> below, the [+/- integer-2 ] is not immediately followed by
>   >> "...", only the entire group of index specification options has
>   >> this repeatition indicator.
>
>   Randall> My read on COBOL-20XX: If foo is a data-name, this is one
>   Randall> subscript.  If foo is an index, this is two subscripts.
>   Randall> Isn't "+ 1" a valid expression?
>
> We still speak '85, and I wasn't looking forward to yet another
> context sensitive rule.  What happened to the attitude that COBOL
> should be implementable on all classes of machinery?
>
>   Randall> There's been some debate on the J4 list about making
>   Randall> parameters of functions parse the same as subscripts, but
>   Randall> there may still be anomalous situations.  The optionality
>   Randall> of the comma will be a burden on COBOL for the foreseeable
>   Randall> future.  Programmers are advised to use parentheses
>   Randall> whenever there is doubt.
>
> 20XX where X > 0.  If they're proposing general expressions in
> subscripts with no better provision for them than you report, maybe
> it should be for large values of X.  I think they're straining at a
> gnat on this one.  I'd offer the choice of expressions in subscripts
> or invisible commas via a compile time switch or a pragma.  Can
> anyone hazard a guess about the scope of the extraneous comma
> problem?  Program editors have improved quite a lot in the last 40
> years.
>
>
>
> --
> This message was sent through the gnu-cobol mailing list.  To
> remove yourself
> from this mailing list, send a message to majordomo@lusars.net with the
> words "unsubscribe gnu-cobol" in the message body.  For more information on
> the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.