Re: [GNU-COBOL] Random followup to Tim's mail

[Tim Josling <tej@melbpc.org.au>]

Good points Chad --- see below.

Chad Slaughter wrote:

>
> >chance to see my work. I think I will finish the preprocessor and put that up
> > on
> The preprocessor would be very cool. We only have a simple one implemented in
> the phase one code. But it serves its purpose.
>
> >the Web for you to see if you like it. At the same time if you have some
> > design
> >concepts and particularly scope I am keen to hear about it. My planned scope
>
> I am working on writing up the design concepts for ppl to look at. =)
>
> > for
> >the preprocessor is:
>
> >1. Handle COPY verb (with unlimited nested includes as an extension).
>
> unlimited nesting is that legal?

No it's non-standard - that's why I referred to it as an extension. But a lot of
the compilers do support some extras here. So it will need to be flagged as a use
of an extension and turned off by default.

> >2. Optionally Expand tabs per user specs.
>
> As per how we did it in our first try, I'd encourage you to use
> the unix util "expand" to do this instead of writing your own.

I already wrote it bu I will ditch it if expand does the job (now that I know about
expand).

> >4. Optionally handle EBCDIC to ASCII conversion and conversion of IBM 72
> > columns to
> >variable format.
>
> conversion of IBM 72 columns?? what is IBM 72 columns?

The IBM mainframe format is:
1-6 sequence number
7 identifier (comment/debug/continuation)
8-11 Area A
12-72 Area B
73-80 Whatever you like (ignored by compiler).
Everything is in EBCDEC character code

The utilities fix this up (convert to ASCII, add \n every 80 characters, optionally
remove cols 1-6, remove cols 73-80,
optionally convert \n to the escape sequence "\\n"). So you end up with something
that can be input into our compiler. The reason for the escape sequence is that in
some mainframe programs, people actually put binary data including newlines into
character strings. So support this you need some type of escape mechanism. I
suspect you might not like this, anyway it would be optional, flagged and
controlled by switches.

> the ASCII to EBCDIC would be nice. and the reverse too. Perhaps a small
> utility ??? =)  do conversion based on executable name. =)

Yes it's two small utilities. Obviously all these little utilities are going to be
orchestrated by a master cobol compiler akin to gcc.

>
> >7. Optionally add extra spaces at end of lines so the full-stops are valid
> >(standard insists they have a space after them).
>
> ??? sounds good. Not that I dont believe you, but I like to know
> which parts of the std are covered by which code...

Well this will be a preprocessor option '--fix-eol' to that editors that trim
spaces from the ends of lines won't cause grief.

>
>
> ok I am thinking out loud again... maybe all code should ref in the
> header comment which parts of the std are relivent to what its doing??
> good yes, no??

The comments in the code do refer to this - I think it is a good idea. The userdoc
will also.

>
>
> >All but 1 and 3 are going - and fully test-cased of course -  so far.
>
> well well thats great. =)  dont sweat COPY and REPLACE just yet.

I am doing COPY/REPLACE as part of the preprocessor, as a discrete unit of work
which is useful. So the main parser needn't worry about C/R. Trying to handle
everything at once is too hard for me, especially given how messy continuations,
comment-entries, adding spaces to end of lines, etc all are.

>
>
> >So the compiler will get a pretty clean and simple file (probably with #line
> >directives in it like C preprocessor for better debug and listings).
>
> *Laura read this part!*
> Ok, I dont like the idea of adding new tokens to the file.
> And I dont like creating extra files..but to prevent me from going off on
> my latest greatest idea(shameless stolen from others of course)
> I'll just say this. I think the preprocessor might write out a file to
> correspond the input source files(including copy/replace files) line numbers
> with the preprocessor output/compiler input file line numbers.
> Then we write a little function to do the look up on compiler errors
> and print out the associated line number from this file.
> good idea? bad idea? what?  might simplify the whole line numbering issues.
> Then as I generate C code, I can use this function to output #line to the
> original files too.  =)

I was just looking to follow the practice of the C compiler and C preprocessor, lex
and yacc which do it this way. It does make the preprocessor output easier to
navigate as you can see where the output comes from (like the output from flex).
from and Xp perspective I would think the #line as the simplest idea taht could
work, and you would I suppress recognition of the #line directives in the
preprocessor, and if in the compiler if the customer bypassess the preprocessor.

>
> (The other idea involves use of structured storage and the software I want to
> use isn't ready)
>
> One thing which needs to be done is to correctly check the column A,B rules
> in fixed column format files. Its a bitch but it needs to be done eventually.

That means flex needs to remember the column numbers which it doesn't do - you need
to write the code yourself, as I did in the preprocessor - you need to do this to
output things in the correct columns. In '95 the AB rules go away, so it should be
a check that can be turned off. The only exception if that the preprocessor needs
AB distinctions to handle default termination of comment entries. In spite of an
attempt to keep it, comment-entries are still out of '95.

000000* note that the only way to recognize the end of the author paragraph here is
that a new paragraph starts in column 8-11.
000000 author.
000000* author paragraph is empty which  is valid!!! So no ". " to terminate it!!!
000000 installation.
000001               lots of stuff.
000001 date-compiled.

> >I am also interested in how we can achieve the 'bazaar' model of
> > development - ie
>
> I think we can do this by practicing XP. =)

I would like to hear from the other team members their views on XP. I would think
it's everyone or noone - either you have all the test cases or you don't.

> >avoiding bottlenecks - how do you partition a compiler.
>
> good question. We've been fighting over this for awhile.
> The main systems as I see them are preprocessor, parser,code
> generator, runtime system. Each of these is rather large and has many pieces
> how well we can break this up is another question.

There is some discussion in the XP wiki about this. They suggest partition by
grammar productions. I think the symbol table is a single point of dependency
though (though I don't know enough about symbol tables to be sure).



--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.