gnubol: subsets

[RKRayhawk@aol.com]

For what it's worth, IMHO, adopting a strategy of subsetting requirements 
could be damaging to our efforts. What is needed now is not either all of the 
code or some of the code. What is needed is design work. We need to know the 
total work to be done by the
preprocessor.  We need to know the interface from the preprocessor to the 
parser(s). We need to know the design of the semantics, and what debugging 
will be like in the ultimate runtime environment. We need to know the 
interface from syntax to semantics. We need clear understanding of where 
syntax ends and semantics begins. We need a complete design of syntax so that 
we can perceive the aspects that would be generalized.

Generally we do need complete design first. Then we can pick and choose what 
to code first. 

It is heretical in amonst all of these other posts, but we do need a complete 
design before we pick our parse tool! Please don't stone me for saying it. 
The messenger just brings 
you the word.  The word is design all first, then pick your tools. Then 
sequenct the coding tasks.

And while you are stock piling your litho weaponry, please patiently consider 
this. We must infact complete the design before we commit to left-hand side 
reduction or right-hand side reduction.  We must know what error processing 
is.  We must know how much the parser(s) will manager type attributes, and 
how much of that will be done in semantics.

We most certainly must design the interface from the parse to the backend 
before we code any serious productions. (That phrase is not meant to belittle 
any of the great efforts made to date. It is just that I think we all know 
there is some serious work ahead.)

So far, we have the following. Numerous excellent grammar experiments that 
amount to a 
successful feasibility study.  Mininum collection of specifications. Many 
valuable annotations
about challenges ... for example ON SIZE ERROR clauses are left associative 
but they associate in a cascade manner right _through_ intervening arithmetic 
statements back to the highest arithmetic statement that has current scope, 
unless its scope is hidden by something that allows blocks of statements 
which might include a conditional arithmetic statement that would in that 
circumstance be the place to associate the clause. So far no one has named 
the parser tool that will handle that in the proper circumstances, much less 
diagnose erroneous code in a robust manner.

I think we do not have a design here.

If 'design' seem too abstract or too inconvenient then please accept the 
words: we need general descriptions of what we will do. Diagrams would be 
nice. If we generally describe each part of the language, and have diagrams 
for most, then we will see not only opportunities for generalizations, but we 
will see that picking the parser tool will be very difficult. Picking the 
parser tool for the feasibility studies was not easy. But your actual 
parser(s), no matter which collection of tools selected,  will be very 
different from what has been tried so far.

I have my shields up now, and my hard-hat is on so lob at me what you like. 
With all the best intentions I say we have not yet commenced work on the 
parser. We can not code yet. Picking a subset is not actually possible at 
this point, and organizing our thoughts around a subset is just a distraction 
that chews up more time. We must know the design.

Recognizing that the compiler deals mostly with errors is the very first 
step, IMHO. If you do not see that, please continue to label this as COBOL2C 
translation. If you wish to stay on your feet no matter what the compiler is 
confronted with then call it gnubol, call it compilation, design management 
of errors into it.  If you think gnubol will actually digest valid code, then 
design semantics before you code syntax. 

The design abstractions that we make in our consideration of data type and 
procedure type will have a manifold effect on the parser, and the interface 
between syntax and semantics. The parser traffics in errors and semantic 
emissions. We have not designed any of these.

I hereby christen each of thee, system-analyst, at this time none of thee is 
programmer-analyst. Your job at this time is to design. Go directly to 
design, do not pass code, do not collect parser actions. 

I believe that we have commenced to orient our work to a left-hand side 
reducer.  This happended while we were focusing on lookahead as an aspect of 
tool technologies that deal with ambiguities in supposedly context free 
languages. I wish to high-light this. We are committing to left-hand 
reduction.  I do not think that commitment is yet warranted, because we have 
not yet done design work. ((Please note as I huddle beneath my shield that I 
am merely saying not yet warranted, I ain't against anything, honest.)).

You can work it in either direction. Design decisions about the 
syntactic/semantic cross-over and design decisions about error processing 
determine certain restrictions in our use of LL or LR tools.  Or it is the 
otherway around; a decision for LL or LR for whatever reasons, could put 
constraints on what kind of error processing you can do, and could put big 
time strangulation on your flexibility to adjust the syntactic/semantic 
cross-over.

All of the tools are great. LL is great. And LR is great. It is all positive. 
We need to design, IMHO, before we choose.  It is an accident that we are 
leaning towards LL. It happened as a side effect of feasibility enquiries to 
determine potential ways to alleviate certain context dependencies in COBOL. 
I think that is also actually out of context. All of the languages discussed 
are context dependent. All of the languages need type information from the 
symbol table to keep the parser(s) on their feet.

The topology of COBOL is that of a not-functional language (beneath my hard 
hat here, I went out of my way to not say non functional, so give me a 
break).  The surface of COBOL is not recursive in general.  Instead it is 
greatly optional. Most of the languages that lend themselves to these cool 
tools around here are functional, and generally characterized by both begin 
and _requisite_ end scope tokens of varying hierarchical significance. COBOLs 
clauses and phrases are not only optional but the end scope elements that are 
available are usually even more optional than the phrase itself, and numerous 
clauses and phrase do not even have an end scope element. But what is worse 
is that the hierachy of scopes is simply determined by what the coder has 
coded so far, not by predefinition of tokens in the grammar tool sript (such 
as a marking of associativity).

COBOL's natural language features are the pieces of a genre. There are 
possibly no tools designed to parse this genre of languages. There is a 
distinct possibility that we have before us a decision that is somewhat 
different than is assumed.

The basic choice seems to be understood to be, we either hard code a 
lexer/parser which we actually won't do because we refuse, or we will select 
the tool that will do this thing for us.

Now I am really well protected down under all this protective armor and 
shielding so just really jump on this if you like. I am sure that if we do 
design, one result is that we will state 
that we must make our own tool. The two strategies would be to really clear 
the design table and really make a new tool, or to chart ways of using the 
exisiting tools in new ways.

But all time spent now coding is self defeating. The good workers of this 
project deserve better than the dismal result that will produce.

You know?! Christmas is near!  It is funny, maybe its this absurd millenium 
thing that the media is making so much hey off of,  it has kind of filled up 
the channel time.  I think Christmas is actually sneaking up on us this time.

Why don't we do ourselves a favor. Lets give ourselves a present. How much 
design work can we do before 12/25?

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