gnubol: transposition comments sought

[RKRayhawk@aol.com]

In a message dated 12/13/99 2:37:31 PM EST, wmklein@ix.netcom.com writes:

<< AcuCOBOL - gets compiler errors
 
 DEC VMS - compiles without errors
 
 Does the list really want me to continue "posting results"?  I am convinced
 that this "extension" is (at least a little) more common than I thought - but
 still haven't heard of ANY compiler that accepts nested conditionals other
 than SEARCH/EVALUATE - but doesn't accept these.
 
 Bill Klein
   wmklein <at> ix.netcom.com
 
  >>


I know I speak for many when I thank you for making your information 
available and making your many contacts available.  You and those contacts 
are extremely valuable for this project. We should conserve that critical 
willingness to run tests. We may find other needs.

I can not speak for the group, some have posted that in open source there is 
no such thing as consensus (and if there were, I know I am not the 
spokesperson). But nonetheless, let me suggest this.  There is a small code 
base issue: some compilers reject, others extend to deal with the nested 
unterminated conditionals. The code base of extenders may not be large, but 
it is large enough to mean we generally may want to remain flexible, without 
commitments at this point. We may want to avoid any decision for an LL versus 
an LR that makes it harder to go reject or extend. (There is a minority of 
one who recommends externalizing the attribute).

I think it is generally agreed that the grammar has to be that complex to be 
robust, separate from the reject/extend decision. Posters who are working on 
grammars, indicate that they will have grammars that can see the code 
circumstance. Lets allow the testing to rest on this issue: we have found a 
small code base behavior distinction.

We are grateful for the posts and very grateful to those who anonymously made 
their time available on those platforms. 

The grammars are perhaps near.  When we commence to try to mature them by 
actually nesting the dangling alternate conditionals inside of the IFs and 
EVALUATEs (and  our nemisis SEARCH) we will find ourselves generalizing. 
Maybe some code base issues can be foreseen there but soon we begin to get 
committed to coding strategies for solving nesting problems.  I think that 
the only issue is do we or do we not open Pandora's box, not how many doors 
do you want to open. 

I for one would encourage conservation of the testing resources.

Short of going back to resources for further testing, can anyone comment on 
the code base and the current compilers' willingness to allow transposition 
of alternating conditional clauses. 

In this project I am sensing that the LL and LR workers are simply saying 
that  they do not want to extend to allow transposition. The basic idea, I 
think, is that is future standard and we can pehaps legitimately put it off 
to the lucky future generation of workers on this GNU compiler. ((I hope they 
will be willing to consider this matter further)).

Posters have indicated that it is in the draft of the next standard, and that 
some compilers (perhaps speculation) allow the transposition of the 
alternating conditional clauses now. In this small issues is a difficult 
fact. We could easily lay down some grammar rules that are very hard to 
extend if we do not prove that the design of the rule structure can someday 
permit transposition. In a more isolated, and entirely personal expression, 
we may be hiding from a critical issue that will eliminate LL parser tools 
from applicable tools for this language. 

((This is entirely personal, but I believe that a test of the appropriateness 
of an LL tool is to proove that it can some day handle the transposition of 
alternating conditional clauses; even if we were to hack the proof out before 
early release. I do not have a computer science background. But I am 
convinced that the alternation creates a k=2 or greater problem. Strapping 
PCCTS to k=1 leads to a self deception.  We will be forcing shift or forcing 
reduce where we do not want either!  I do not have the background to support 
this further claim, but I think even the two branched pattern of positice + 
negative conditionals makes it impossible for an LR like bison to deal with 
the internal statement_block unambiguously, if we have naive rules. K is > 1 
already.  It becomes much more clear when you try to transpose the 
alternating conditionals. I am recommending trying to transpose as a means of 
self-enlightenment. And I am entirely in favor of succes for each tool being 
tried. :-)  ))

(((Triple super-duper aside, all this is true of the unterminated nested 
EVALUATE within a SEARCH; except that the X-WHEN lexical mode stack can help 
either the LL or the LR tool! )))

So anyway, you can reject that as negative B.S. if you like. but entirely 
objectively it seems worth considering the question: do we have a small code 
base issue if some of the current COBOL '85 compilers are allowing 
transposition of the conditionals? Can we make any assessment of this from 
current tests and current available knowledge of project participants and 
project commentors.

Are there any COBOL '85 like products that are extended to allow transpostion 
of alternating conditionals?

Approximately how large is the code base of actual programs with transposed 
conditionals? 

Can experienced people give us any sense of what would happen to a project 
that tried to move from such an extended compiler to an early release of 
gnubol without such an extension?  Is this big enough to worry about?

This would be a request for comments not a request for wide spread testing at 
this point.

Thanks,
Bob Rayhawk
RKRayhawk@aol.com


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