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

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

Chad Slaughter wrote:

> dont mean to dis your code. But the  reasons for using an external
> utility in this case were b/c tabs are technically illegal characters in
> Cobol. and so should be treated like that. But I have no problem adding
> the option to convert the tabs prior to compiler execution
> using the "Big wrapper program"[tm]

>>> agree, my tab expansion is external too, run as an option.

>
>
> >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
>
> oh thats the same format Microfocus used. And which we also implemented
> in the first preprocessor.
>
> Which reminds me of another issue the Right margin. The right margin is
> an implementation defined value. The std only says it must be finte. =)
> or defiante or something like that.
> Since I think we ahve to define it I ma thinking 2^32? sounds like
> a good value to me or 2^64 or maybe just 2^[word size] =)
> Just a random thing...

>>> The std doesn't actually *say* the margin must be the same on each line. So you
could say 2**32 or the actual line length whichever is shorter. The problem with
just saying 2**32 is that you end up with some very long continued character
strings. (gnu fortran had a similar dilemma).

> jferg: ummm...could put a page to list the implementation defined shit
> and what we decide to use, etc. Another thing... you could put up
> an page that looks incredibly similar to, but yet completely different
> from I-10 to I-39 of the std..so we can track what we have implemneted
> and such.

>>> good idea

> Which reminds me...the sequences numbers actually have menaing..I think
> when it comes to either debugging or listing printing..someone said something
> sometime about it. But I dont remember. =) anybody have any idea what
> the fuck I am talking about? if not just ignore as always.

>>> the standard is big on 'listings' and you have to keep the sequence numbers for
the listing actually.

>
> >optionally convert \n to the escape sequence "\\n").

> ...
> You're right. I dont like this. Fuck the mainframers! =)
> kidding. No the way I think this should be handled is to modify the
> character strings instead of the source code.

The trouble is, if \n is the line delimiter then the lex thinks it had a partial
non-numeric lit which should be continued etc. Any the next  'line' would just have
the rest of the string , uinstreat of  >>000000-     "restofstring...".
So the only way I can see to allow the newline in the EBCDIC is to have escapes or
as you suggest, hex n-n-lits (which are in '95). But hex lits are very unreadable!

> ok, well what I want to know is why we are doing this??
> yes some text editors are stupid. But is it requered that the space
> be ther in the std? and does the newline count as this space?
> I am asking cause I dont know.

>>> That's my reading. IBM's manual refers to an extension, whereby a non-num-lit at
the end of the line need not be followed by a space, so I think they agree with me.
It sort of depends how pedantic we want to be - I think we let the user decide and
we do what they want. The big argument is later - what is the default? Or maybe we
have master-options like --sensible or --pendantic.

>
>
> or do you mean handling all of cobol in one parser? yes, that is true. =) (that
> it's too big)

>>> yes so I think COPY and REPLACE in the preprocessor.

> In this case thinking it was like C was easy, until you realize it
> doesnt work.
>

>>> Yes COBOL is not C. The rules about arithmetic for example.

>
> >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).
>
> I do understand this, which is why I suggested the lookup file.

>>> I was thinking of the user browsing the preprocessor output, thinking 'what in
the ... has it done to my beautiful code' and trying to relate the output to the
input. Having it all together makes it easy for them. Somehow we need to pass the
info from the preprocessor to the main compiler. Having two files makes me nervous
because you get the chance to move rename lose one or both - also means you can't
pipe the output from pp to compiler.

>
> This is an important difference between C and Cobol. In C, you can by pass
> the preprocessor, as its not even part of the langauge. In cobol...our
> "preprocessor" _is_ par t of the langauge and can not be bypassed.
>

>>> You are right. But it
* there are no copy/replace
* there are no continuations
* no comment-entries (like 'author' etc)
* etc (can't remember the other ugliness)

Then the user could say to skip the preprocessor and save compilation time.

>
> It also need AB distinction for the rest of the program too.
> Certain verbs can only appear in A or B.
> Also the replace/copy semantics depend somewhat on the Area in which it
> occurs.

>>> true, we need to be AB aware and the preprocessor needs to follow those rules

> >000000* note that the only way to recognize the end of the author paragraph
> > here is
> well we cheat adn solve this problem , by simple searching ahead to the
> next division statment, if any.

>> can you clarify this for me

"Where is the wiki on compilers?"

See. http://c2.com/cgi/wiki?ExtremeProgrammingChallengeOne

Highly recommended.
Sorry if this was rambling but I am home from work sick with a cold - it is Autumn
after all (in Melbourne Australia).

Chad I printed out your other thoughts and will think about them.

Regards,
Tim Josling




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