[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: STODGY and GNUVEAU compile
RKRayhawk@aol.com wrote:
> 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.
Yes, creativity is good. However, before you can turn clay on your pottery
wheel, somebody's got to go dig the clay out of the ground. Creativity is
meaningless until we have a method of expression. Right now, we should be
building a method of expression. Then, we can be creative.
Basically, my opinion is:
1) We should not be trying to put pointers into gnubol, for the initial
release.
2) WHEN the initial release is ready, IF pointers obivously exist in the
implementation, and IF it is decided to support them in gnubol, they should be
done in the COBOL 20xx style.
> Many innovations are relevant. A CLARK-POINTER is definitely a useful idea.
PLEASE, tell me you forgot to put a smiley on that... Especially since I
prefer to dodge pointers whenever possible. :-) (Although, I must say the idea
of having an entire datatype named after little ol' me does seem rather...
stimulating...)
> 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.
Hmm... This basically looks like syntactic-sugar for reference
modifications to me. Given (well, you called them CLARK-POINTERS...)
* The code that goes here is left as an exervice for the reader.
01 EARL-POINTER USAGE CLARK-POINTER.
01 EARL-NUMBER PICTURE 99.
01 JAYNE-POINTER USAGE CLARK-POINTER.
01 JAYNE-NUMBER PICTURE 99.
01 CHRISTOPHER-BUFFER PICTURE X(32) USAGE CLARK-DATA-8.
* conceptually: PICTURE X OCCURS 32.
01 CASSANDRA-BUFFER PICTURE X(32) USAGE CLARK-DATA-16.
* conceptually: PICTURE XX OCCURS 16.
* The code that goes here is left as an exercise for the reader.
* The statements
SET ADDRESS OF CHRISTOPHER-BUFFER TO EARL-POINTER.
MOVE "E" TO CHRISTOPHER-BUFFER(EARL-POINTER).
MOVE X"FEFF" TO CASSANDRA-BUFFER(JAYNE-POINTER).
SET JAYNE-POINTER UP BY 1.
* Are effectively equivalent to
MOVE 0 TO EARL-NUMBER.
MOVE "E" TO CHRISTOPHER-BUFFER(EARL-NUMBER * 1:1).
MOVE X"FEFF" TO CASSANDRA-BUFFER(JAYNE-NUMBER * 2:2).
ADD 1 TO JAYNE-NUMBER.
(Cassandra Jayne Clark being what my parents were going to name me if I'd
had 2 X chromosomes instead of 1. <grin>) Pointers haven't really gained much
here. In fact, you've lost something, since you could possibly use the same
numeric variable in both reference modifications, whereas EARL-POINTER is bound
to CHRISTOPHER-BUFFER, and JAYNE-POINTER is bound to CASSANDA-BUFFER.
And yes, that's the right way around. You set the buffer (which is in the
linkage section) to where the pointer is, not the other way around.
> 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?
Ah. Methinks this is the smiley.
The isolation issue is perhaps the most interesting part of this, especially
since _any_ extension to COBOL permeates every facet of the compiler, from
lexing to code generation. (As opposed to, say, C, where the majority of the
``language extensions'' in the new standard are library changes that didn't
change the compiler, and have, in fact, already been implemented on many
compilers).
> But we get ahead of ourselves.
Not necessarily a bad thing. But I don't believe it's appropriate to be
looking at extensions right now. The ability to provide extensions, yes.
Extensions themselves, no.
Any extension to the compiler is going to require hooks into every part of
the compilation process. From lexing (TCP-SOCKET is a valid reserved word),
through parsing (TCP-SOCKET is a valid device-name in a file ASSIGN), up to
generating code to open a file defined as ASSIGN TO TCP-SOCKET "www.gnu.org:80".
So, what hooks do we provide into the main execution line? Can this sort of
runtime modification be done with the lex/parse tools being looked at?
--
Christopher Clark compudata@cadvision.com ICQ#9342023
I don't even dream of being able to speak for my company...
Due to circumstances beyond your control, you are captain of your fate and
master of your soul.
--
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.