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

[Brian Tiffin]

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
>