Re: gnubol: STODGY and GNUVEAU compile

[RKRayhawk@aol.com]

Of course we do get ahead of ourselves when we discuss or code for 
extensions. But the open source phenomenon brings out creative energies that 
are valuable because of the ideas
created AND because any one who works on it usually does other work that fits 
in the mainline.  Sometimes, not always, but sometimes if you quash the 
creative endeavor you loose the other part, the mainline part where they fix 
some other thing to squeeze their idea in.

I think that creativity is also important because the standards committees 
can't do it and it is needed, especially to get the business applications to 
the net. So I hope that we can evolve a
way to capture it, but still allow for a compiler that is straight laced as a 
variant.

Many innovations are relevant.  A CLARK-POINTER is definitely a useful idea.  
I hate to use
reference modification for string scans.  I find that REDEFINES defeats the 
cross reference tool (and that counts big time when I am under pressure), and 
it reduces auditability of code. And STRING and UNSTRING, ... unfortunately 
the real data just does not want to cooperate with the plans of mice and men, 
the delimitters are just not there (and STRING and UNSTRING do not have 
ELSE/OTHER phrases).  So you have to take the matter into your own hands 
often. And it would sure be nice to reference the dataname itself and not 
have to have convoluted syntax.  

I think that a CLARK-POINTER would be great.  It would be superb if an 
expression like 
data-name(some-clark-pointer)  syntactically clarified that I was refering to 
a byte, just because of the type of the pointer.  I would exit the 1950s at 
long last.  Of course I could then point out that if I had draped the 
data-name with the attibute  16-bit-data (such as with a DBCS token of some 
kind, like the G in picture clause over there in  the real world, or perhaps 
yet another new world token to be invented to designate the thing as 
CLARK-DATA-16), I naturally expect the parser coder to understand that I am 
referencing  the ith 16-bit element. As long as you have type information 
percolating up in the parser it is a piece of cake.

I'd like to protect every one who hates it as a
dangerous invasion on their data division. So I like the idea of a CLARK-DATA 
attribute to narrow the domain of such new world mechanisms.

And I wanted to engage the original proponent of the various SET syntaxes 
both technically and in a manner that illustrates the need to isolate 
experimental syntax. The stuff is good. Isolation is a project management 
concept and a technicians challenge. How do we do it?

Folks who step forth with creative ideas have energy.  I, for one, want to 
channel that energy.

If there are those who would like to find ways to isolate experimental 
features while manitaining respectful interactions with innovative 
contributors, I suggest we use the CLARK tokens in the examples.

By the way someone was kind enough to point out the POINTER redefine hack as 
a way of adding one to a pointer (you add 1 to the redefine name).  One thing 
I think that would be a very very very super very good extension to COBOL is 
to trap any redefinition of a pointer; and optionally, parametrically, error 
it out.  In a sense a POINTER redefined is a clear signal
that the coder intends to violate standard syntax rules. If the standard is 
silent or actually says you can't stop them, then you can't. But I can 
imagine financial environemts in which it might be reasonable to flag or 
error out any such encodings.

But we get ahead of ourselves.

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.