Re: gnubol: refmod again (fwd)

[Michael McKernan <mck@tivoli.mv.com>]

>>>>> "Tim" == Tim Josling <TIMJOSLING@prodigy.net>
>>>>> wrote the following on Fri, 03 Dec 1999 02:10:00 +1000

  Tim> As far as I can tell there is no extraneous comma
  Tim> problem. Commas as separate tokens mean *nothing*, except in
  Tim> literals and PICs and maybe as a substitute for a space. The
  Tim> lexer can throw them away.

Badly phrased.  I was asking about the magnitude of the problem if j4
were to rescind the noise rule.  

I apologize for using the list's bandwidth to grouse about the
standard.  It's not justified for someone who didn't take the time to
fight the good fight at the right time.  I haven't been much
concerned about the standard for the last dozen years or so, so I'll
cut it out, right after this post :-)

  Tim> You are looking for a way to delimit two arithmetic
  Tim> expressions in a function call or (in Std COBOL 4) in an array
  Tim> reference. There is no way other than "the next token can't
  Tim> fit as part of the previous expression". They have just enough
  Tim> rules to make it unambiguous (eg unary plus/minus must be
  Tim> preceded by stuff that could allow the unary plus/minus to be
  Tim> interpreted as a normal plus/minus).

Remember when COBOL was touted as a language that could be read and
understood by your manager? (in recent times, the phrase would have
been "by the PHB".)  OK, it was never true, but it was a worthy
objective. nonetheless.  I'm afraid we're creating a language that is
unintelligible to the cognoscenti of computer linguistics.  This
isn't progress, in my view.

>>>>> "Tim" == Tim Josling <TIMJOSLING@prodigy.net>
>>>>> wrote the following on Fri, 03 Dec 1999 02:20:49 +1000

  Tim> Michael McKernan wrote:
  >> 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.

  Tim> When the previous expression runs out of steam, the new
  Tim> expression must start.

So we adopt a greedy parse strategy.  User, be warned!

  Tim> Very flaky isn't it. What about if the person says: x=function
  Tim> average(a +1 b) << three terms having meant to code: average(a
  Tim> + 1 b) << two terms

Too many whatifs for my finite brain.

  Tim> You have no way of knowing. By the way this problem exists
  Tim> now, in function call arguments. In Standard COBOL 4 draft it
  Tim> also exists in array references.

Lovely.  Jonathon got to do those while I went on to the ports.
Never knew what I missed.

  >> 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.
  >> And, of course, I remain annoyed if I can't distinguish a
  >> subscript from an expression without interrogating the symbol
  >> table.

  Tim> Not pretty but there it is.

I suppose I can deal with that.

Best regards,

Mike






--
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.