[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: refmod again (fwd)
>>>>> "Bill" == William M Klein <wmklein@ix.netcom.com>
>>>>> wrote the following on Wed, 1 Dec 1999 22:37:06 -0600
Bill> I am new to the list - and to this thread, but a couple of
Bill> comments that seem relevant to this thread:
Nice to see you here. I wondered if you'd visit.
Bill> 1) Commas are LEGAL (when followed by a space) WHEREVER a
Bill> space is allowed (except for one odd case at the end of a
Bill> PICTURE string). This means that
Bill> Move, foo (index, +, 1, 2), to, whatever is perfectly legal
Bill> (in '85 Standard COBOL) and is treated exactly as Move foo
Bill> (index + 1 2) to whatever.
Bill> Therefore, giving ANY "real" syntactic meaning to commas is
Bill> (and probably always will be) impossible.
Sure, the whole world and I have been lexing them out for years, but
if we don't have commas, we need something else and I hadn't heard
what it is.
Bill> 2) Using arithmetic expressions as subscripts is definitely
Bill> in the next Standard (and already allowed as an extension by
Bill> many - but not all - COBOL vendors). The recent J4
Bill> discussion made it clear that you MUST include an arithmetic
Bill> expression that STARTS with a unary operator in parenthesis -
Bill> when used as a subscript. Otherwise, you need not use them.
Bill> Thus,
OK, that helps. It still leaves the context sensitivity trying to
distinguish subscripted ref's and separate expressions, though. I
would have hoped that could be done syntactically.
Bill> Elem (data-item + 1) *> uses a single arithmetic
Bill> expression as a subscript Elem (data-item (+ 1)) *> uses a
Bill> data-item and an arithmetic expression as two subscripts Elem
Bill> (data-item +1) *> uses a data-item and a signed integer
Bill> (which is a valid arithmetic expression) as two subscripts
Bill> Elem (data-item (+1)) *> is semantically identical to the
Bill> previous example
Bill> 3) Can someone help me understand the comment, "If they're
Bill> proposing general expressions in subscripts with no better
Bill> provision for them than you report, maybe it should be for
Bill> large values of X." What do you think is missing? There are
Bill> rules for "subscript out of bounds" (which are more explicit
Bill> than those in the '85 Standard).
You caught me being grumpier than usual, but I wasn't even aware of
the rules you just cited, and I don't care for the notion that we
"just do it". These rules do reduce the ambiguity, but they sure
ain't elegant. And, of course, I remain annoyed if I can't
distinguish a subscript from an expression without interrogating the
symbol table. (I suppose I should ask if nested subscripts are in
the game.) I've been around long enough to know what lengths the
committee will go to to avoid invalidating existing code, but this has
reached the point that reconsidering the preservation of the comma as
noise might be in order. I have a feeling that this would cause
little real hardship, but the proposed arcane syntax will be with us
until COBOL really does die.
Bill> 4) From the title of this "thread" (and not seeing what went
Bill> before), did this begin with a discussion of what to do if an
Bill> arithmetic expression as the start position or length of
Bill> reference-modification doesn't evaluate to be an integer? If
Bill> so, this is "explicitly" implementor defined. I know that
Bill> *some* currently CONFORMING implementations round, others
Bill> truncate, and still others give run-time errors - all are
Bill> "legal" as the definition of "arithmetic expression" is
Bill> totally implementor defined.
Hadn't even gotten around to worrying about that one. It's a
semantic issue. I think I started this thread, with no more than a
remark in passing about how to regard refmod. This group (myself
included) is as bad as any about hanging the next comment on whatever
thread happens to be open.
Bill> 5) Concerning Randall's comment about parameters passed to
Bill> functions versus subscripts, I *think* that they are
Bill> identical already in the draft Standard (but I could be
Bill> wrong) with the single exception (which is documented as
Bill> INCOMPATIBLE change from the '85 Standard) that you *must*
Bill> use a set of "empty parenthesis" to indicate "empty
Bill> parameters" to a function which CAN take zero or more
Bill> arguments, i.e.
Bill> You still have Move Function Current-Date to whatever but
Bill> now have Compute num-field = Function Random () or Compute
Bill> Num-Field = Function Random (seed-value)
Bill> ***
Bill> Does this answer any of the "real" outstanding questions, or
Bill> should I have stayed quiet until I "caught" up on what the
Bill> real questions/issue are/were?
It's certainly helpful. You should realize that the originators of
this project committed themselves only to the '85 standard and
there's been no official departure from that, so this has been a bit
of a tangent.
Bill> 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.
Bill> -- This message was sent through the gnu-cobol mailing list.
Bill> To remove yourself from this mailing list, send a message to
Bill> majordomo@lusars.net with the words "unsubscribe gnu-cobol"
Bill> in the message body. For more information on the GNU COBOL
Bill> 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.