gnubol: random thoughts

[Chad Slaughter <slaught@advancenet.net>]

Hello all,

Been busy the last couple weeks and unable to get some email off.
But i have been working on a new symbol table and ir for the parser
and runtime stuff.

A have seen a couple questions come across the list and some discussion
which i had some comments on. 

I also had a question.

How much of the cobol std can be implemented in cobol?
Now cobol is not a system language and never will be, but some of the 
functionality maybe implemented in cobol itself? My question is
what parts would these be, if any?
Basically, if we can implement a small subset in C/C++ and then
implement the rest on top of that in cobol itself, that would be
wonderful and make things easier. Simplify the runtime system and allow
for extensions. 


on with the other comments.

There was some questions about group goals.  I want to reiterate what 
I feel the goals are and why.

1) Create a ANSI 85 compliant cobol compiler.

The ANSI 85 is to limit the scope, now lucky for us, inside ANSI 85
there exist many subsets  to simplify things even more.

The reason laura and I decided on the 85 was for 2 reasons. One it was/is
the latest standard of the language. Yes we should look forward to the
future, but frankly i don't think waiting on the ANSI committee for the 9x/0x
std is worth it. Furthermore, it seems some ppl are still using the 7x std.
Which is only partially incomplatable with 8x and completely incompatible
with the 9x/0x std, due to deprecation in eh 8x std.
Second reason, was the X/Open ppl have a  Cobol std which is based on 
the 85 std with modifications for unix environments. Particularly, the
free form code format, the removal of all deprecated constructs and a few
others. There is a diff from the 85 std out on the x/open web site somewhere
I'll get a url later.

Extensions: mainframe/microfocus/personal
The cool thing about ANSI 85 is that it anticipated extensions and built
the ability to add them into the std.
Now someone was wanting to be able to use PREFORM instead of PERFORM
And there was some discussions bout modular lexer, and stuff.
I dont know if anyone brought this point up, BUT that is completely
unnecessary. THe language defines mechanisms to handle this.
Specifically Replace.
If you read the std(XII-1) about Copy and Replace you will see that they
exist so you can go in and basically 
"[...] COBOL source program can be written in a programmer
defined notation which, at compile time, can be expanded into syntactically 
correct phrases, clauses, and statements."
Third paragraph, 1.1 on page XII-1 of the ANSI 85 std.

Basically, this whole situation is solved by the preprocessor which Tim
has written to handle the copy/replace. Check it out. If you
want these extensions try figuring out the copy/replace statements
necessary to implement the extensions. Try it out. Test Tim's preprocessor.
This goes along with my question above about implementing certain features
in cobol itself.


2) using C as an intermediate language.

 While the web pages, which I'll get changed sometime soon, says
Cobol2c this is really a misnomer that I apologies has been allowed
to continue.  Yes, we are using C as an intermediate language, but its 
not a final product. I am using C because every other language that has
been added to the GCC suite has previously used C as an intermediate 
language.Fortran, obj-c, c++,pascal?.  
There are several reasons for this.
1) More ppl know C then RTL. 
2) Its easier to refactor common generated C code into a runtime library
then to try and backport RTL.
3) the documentation for RTL is limited. Last I check there was the GCC
info files and one web page. There may be more, but why bother?
4) Attempting to track the gcc source at this point would be a bad idea[tm]
And we would have to do it or risk breaking off form them. If we use
C we can have access to all the latest code with no effort. If we try to use
RTL we have to shoe horn our code into there model from the beginning.
I think ppl should be able to use the compiler without having to unload
a 12 meg file. 

Our first release had a nice driver program, that would take in a cobol src
and generate and executable all in one command. is there something wrong with 
that? If the effect is an execute what's the problem? *shrugs*

If someone could answer my first question that would be great.



-- 
Chad Slaughter  -- slaught at advancenet.net

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