Re: gnubol: STODGY vs GNUVEAU

[RKRayhawk@aol.com]

Concerning alternate (mis-)spellings like

<< 
 ln PERFORM PREFORM
>>


Some of that _could_ be handled by the lexer. Some folks talk about leveling 
THRU and THROUGH, as well as SPACE/SPACES or even OF/IN (OFIN has exceptional 
considerations). So that either of the pairs simply return the one token 
known to the parser.
((I like the leveling idea per se because it offers certain efficiencies in 
parser tables, and rule enumeration. Although alternative _new_ spellings 
actually increase the lexer's table size.)).

There must be oodles of ways to do this, but we need to be able to exclude 
it. In some work places a spelling such as PREFORM can not possibly be 
accepted. And certain tool users (compiler users) would not accept the 
project's result if the PREFORM alternative was even present at all in the 
executable.  So, ... we _might_ want to make our variability more than just a 
conditional compile, or conditional invocation of a module.

My thought is that we need the equivalent of conditional compilation 
directives in the lexer specification and the parser specification. I think 
we need a proof system, that can conditionally scan the lex and the grammar 
spec and emit the actual spec to go into alternaive gens of the compiler.  I 
am not sure that all the available tools will support that, so we may have to 
use sed, perl, awk or rollyourown against _the_lex/parse_spec_; and thereby 
drive alternative compilers. 

I am thinking that we need to make the absence of the 
alternative/creative/experimental features very auditable.

I am thinking that someone says lets down load the GNU COBOL compiler but not 
bring down the new stuff. And an informed tech says we'll get it, and just 
set the parms to gen the conservative stuff, and the decision makes says no.

There is data out there that deserves to be protected. For COBOL the build 
has a different taste. The radicals will not say "don't build the new stuff". 
The radicals will say "do not download the newstuff into our environment at 
all." 

I, for one, wish to support the radicals AND the experimenters.

This is a technical challenge. I think that the GNU COBOL compiler project 
has a different success criteria for acceptable build components, in contrast 
to other GNU compilers. We cannot just be as flexible as possible. 

For some users, the most flexible build set is highly desirable. Yet for some 
a very tight standard compiler is the only thing useful.

Our challenge is that as programmers and compiler hackers we are immersed in 
conveniences that allow optional expressions (like conditional compilation). 
We need scrubbers to cleans the driving source file thoroughly for the 
conservative users. IMHO.

I think that there are two types of scrubbees. First any experimental syntax, 
or non standard tokens.  Second anything that hooks to the internet 
syntactically; this second category does not delete the CALL mechanism from 
COBOL and does not disallow or deal with any API of any type. Go ahead and 
call anything, plug into any socket via standard syntax. The link environment 
and operating system are the user's concern.

Certain kinds of lexeme folds like SPACE/SPACES might be non-scrubbees. 
Depending upon our guess about liguists sensibilities a fold like IS/ARE 
might be a scrubbee.  Generally, a fold like PERFORM/PREFORM would be a 
scrubbee. The reason for suggesting a gray area is that performance, which 
_might_ be marginally enhanced with a fold like SPACE/SPACES (because of rule 
proliferation containment) could be a more important consideration than 
differences that don't make a difference in the standard. 

I hope that the original proponent does not take any of this personally. I am 
not after restricting PREFORM.  I am after achieving a means to isolate our 
experiments, while fostering their development.  Just for example, I would 
love to see a new lexical entry DO to be folded with PERFORM, and an END-DO 
to be folded with END-PERFORM. For after all, COBOL is not only verbose, it 
is keystrose! We could fix that.  There is no reason that we can not try to 
find a way to make the COMPUTE token entirely optional.  It could be hard. 
But still. Why not try.  

My point is that we need to really scrub that out of a straight lace gen. 
(Speaking in lex and bison terms) we need to have *.l and *.y files that have 
none of this stuff. A person should be able to do a download and get only 
cool calm *.l and *.y files, and only the libraries and config files that go 
down Standard Road.  Yes, I know this is way out there at first glance, but 
even if we need to subset clib!  If they want the whole lib go get it. But we 
should re-arc (or whatever) to get the sockets out for the more radical users.

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.