gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] How does Cobol parse the Procedure Division ?


From: Patrick
Subject: Re: [open-cobol-list] How does Cobol parse the Procedure Division ?
Date: Tue, 24 Sep 2013 20:55:59 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130917 Thunderbird/17.0.9

Hi Brian

Thanks for yet another helpful post :)

If you ever get a png generated and feel like uploading somewhere, I bet lots of us would love to see it too.

BTW I have received quite a few responses addressed only to me when I think they were intended for the list. Has there been any changes with how sourceforge handles the list?

I am trying to warn people, some of these posts have been really really excellent and we could all benefit.

Thanks again-Patrick




On 09/24/2013 08:41 PM, Brian Tiffin wrote:
Patrick;

Nothing left to do but smile, smile, smile.

When we get to GNU, I'm going to point out that I'm of the belief that
OpenCOBOL is very likely the most complex flex bison usage in the free
world.  I'm hoping to pique interest in the other august GCC compiler
authors and teams.

But, yeah, think of periods as end of sentence, breaking out of all
control flow scope, however deeply nested.  Hmm, that's not a correct
enough description.  Sentences don't end section control flow, but do
end paragraphs, being the implied return.  Periods do break out of any
(and all) IF ELSE IF IF IF ELSE blocks.   I really like the
flexibility of modern COBOL, but I'd suggest keeping periods out of
control structures.

I try and write single sentence procedure divisions.  ocdoc.cob is one
of my favourites, (and is full of so many frogs that it's likely a
pond more than a source listing). But named sections and paragraphs.
are pretty handy once the refactoring pass comes due.

In my humble, biased, personal preference, try to avoid periods in the
PROCEDURE DIVISION, use them purposefully.   And, the parser has
'assumed' statement terminators when it bumps into verbs (or labels or
...), so most statements don't need a full stop, even when chained
together in run on sentences.   ADD will assume END-ADD when it sees
another verb, etc, as does MOVE.

Again, I prefer to use full stops purposefully, and only when needed
to end a sentence or paragraph. (or section or program or ... for the
most part, all 'paperwork' COBOL words and phrases.)

But, OpenCOBOL is flexible.  Section programming, fixed, free, giving
us all a lot of style and 'best fit for this' options.

And yes the parser and symbolic tree used in OpenCOBOL is complicated.
  It breaks most visualizer software I've tried.  All really, but as I
type this, Graphviz is busy churning over the .dot file generated by
telling the parser generator, bison, to use -g during the compiler
build.  It hasn't given up yet, and it's been pounding 100% on a core
for getting on 30 minutes now.  Could well be spinning, but I'm
willing to wait it out for awhile.  2700 nodes, some 9000 arcs.  If it
completes, the .png will be HUGE.  I hope it works this time.

Cheers,
Brian


On 9/24/13, Ron Norman <address@hidden> wrote:
periods are not required to end a single statement but do act as a final
scope delimiter.

To find the history on this you would have to go back to the 1960's and
Grace Hopper.
I recall published standards for Cobol 1968, 1974, 1985 and then 2002.

Cheers,
Ron Norman


On Sep 24, 2013, at 15:44, Patrick <address@hidden> wrote:

  Hi Mike

Thanks once again for your helpful feedback.

I am not sure if I have any real proposals here for open Cobol but if we
could continue the discussion without a fight breaking out, something
valuable might come out of this.

I am a recent learner and the periods VS END-verb was very confusing for
me.

At 37 I guess I am a "young" coder and I don't mind the END-verb at all. I
would also have been happy with periods too but I am not happy with
implicit statement ends, this reminds me of JavaScript with optional
semi-colons.

If everything was just periods or END-verbs it would be so much easier to
learn. Furthermore some verbs do not have an END-verb option such as MOVE.

Does anyone know of anywhere I could read about the discussions that might
have taken place about this?

It seems to me that having 3 different ways to end statements was a way to
keep everyone happy and that thousands would be furious if their style was
omitted.

Again I don't really have a suggestion that would not upset others but
maybe if I understand the problem I can figure out some little work around
or at least give tips to others in a tutorial-Patrick








On 09/24/2013 01:21 PM, Michael Anderson wrote:

    Patrick,

In the past a period was always required to terminate a statement. It was
the onset of the END- verb that made the period completely optional, except
at the end of a division, or paragraph. There has been discussions between
many cobologists to remove the period completely. However, points you
mention, as well as others, make this impossible. However, a negative
consensus of Cobol (by non-Coboler's) has been that it is too verbose, too
wordy. In my opinion the END- verbs add to this wordiness, and is perceived
negatively by young new programmers learning the language, a single
character is much more preferable.

There is a difference between reserved words and verbs in Cobol. For
example “STRING” is a verb, and a reserved word, but “INTO” is not a verb,
but is a reserved word. I think you're correct in that it is the next known
verb that terminates a statement without a period.

I would agree that this END-verb verses using a period does probably add to
the complexity of the parser, but this also adds to the complexity of
learning the language. For example; some programmers use END-verbs all the
time, others are not as consistent. Also the compiler will warn of missing
END- verbs, but they're only useful to me when coding within the context of
upper level verb. So, what is the deal?

  Too me, this feature is useful for readability.

I don't use END- verbs all the time, but when I do, I prefer it to be only
within the context of another verb. For example: “If, Evaluate, in-line
Perform's and so on..... When NOT in the context of another verb I always
use the period, and never the END-verb. I'm definitely not trying to push
my coding style on anyone else. However, this makes my code better for me,
more readable for me. Especially when looking at large junks of code with
END- verbs lets me know I'm working within the context of a higher level
verb. Where periods are used in my code, I know without a doubt, that I am
working at the outer most context of verbiage. As this madness may upset
some traditional programmers, I give much thanks to the compiler guys for
supporting this feature. I also prefer FREE FORMAT without column
constraints, which also increases the blood-pressure of traditional
programmers.

I also prefer to work well with others, so when asked, I have no problem
replacing all my periods with END- verbs, but for me this does take-away
from the readability and adds to the wordiness.

--
Mike.

On 09/24/2013 10:07 AM, Patrick wrote:

Hi Everyone

It's easy to see how Cobol can be parsed in all of the parts outside of
the PROCEDURE DIVISION, statements end with periods.
I can't see how the compiler could understand what is going on in
PROCEDURE though. Every language I know of has some sort of character to
end a statement. It might be a non printable character but it's there.

PROCEDURE ends in a period and paragraphs end in periods but if we have
a statement like this:

MOVE foo TO moo

I could see how the compiler would implicitly know that it ends one
token after TO but we can also have:

   MOVE foo TO moo koo boo

Does the next reserved word that is not a part of the current sentence
signify an end to the current statement and the final period indicate
that there are no further statements coming ?

If this is true, was it always this way. From what I understand it was not.

If this is true did it dramatically increase the complexity of the
compiler?

Thanks



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing
address@hidden://lists.sourceforge.net/lists/listinfo/open-cobol-list




------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from


the latest Intel processors and coprocessors. See abstracts and
register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk


_______________________________________________
open-cobol-list mailing
address@hidden://lists.sourceforge.net/lists/listinfo/open-cobol-list


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list




reply via email to

[Prev in Thread] Current Thread [Next in Thread]