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

["Chad Slaughter" <slaught@umr.edu>]

Hello all,

Tim,
I think we are agreeing on most everything here. Its just we are talking 
past each other. I think. Unfortunatly, I am currently sick too. =)

One other thing, can you try and keep your mail messages under
80 chars per line. Preferable around 72, so replies dont wrap and stuff..
Just a minor point nothing big.=) 

Tim Josling wrote :>
>Chad Slaughter wrote:
>> 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. =)

>>>> The std doesn't actually *say* the margin must be the same on each line. So you

Well, the std says you have to choose a size for the area B, adn it 
has to be finite. and thus you define the _max_ right margin.

>just saying 2**32 is that you end up with some very long continued character
>strings. (gnu fortran had a similar dilemma).

huh? I am not sure I know what the problme is here.
Mainly I am saying call the max line length, max file size. *shrugs*

>> Which reminds me...the sequences numbers actually have menaing..I think

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

yeah, =P I hate listings. somebody put that on the list of thing sto do.
setup the ability to generate listings.  =)

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

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

ok, I am confused as to what the issue here is?
I still dont understnad why its a problem. 
the offical scanner/lexer will not know anything about line continuations
if that is your concern.
Also the binary data in strings would be converted to hex, prior to
the preprocessor getting ahold of it...at least that was my first thought.
ie change teh characters from ebcidic to ascii and encode in 8-bit characters
in literal strings... am I missing something?
i probably am. =)

>as you suggest, hex n-n-lits (which are in '95). But hex lits are very unreadable!

so? only the compiler will see it.

I am not much for user readable generated code. =)

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

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

ok...well. umm my question is where in the std it talks abut this?

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

Yes, I agree with you.  =)


>> 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.
yes, thats one thing. But there are more. And in this case, I was talking
about how the compilers have to work.
In this case the C preprocessor is an option hack! 
But our "preprocessor" is required for teh cobol compiler to even work.

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

well, as I said above. I am _not_ into making generated /intermediate 
code human readable.
Second they should *never* have to look at the intermediate code.
The only time it will be neccessary is when we are debugging the compiler.

>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

well the second file will only be for proper compiler warning/error outputs.
so we can say its line X in file y: error this.

I personalyl dont like it either, but the alternatives, right now,
I like even less. Its the simpliest thing we can do that works.

>because you get the chance to move rename lose one or both - also means you can't
>pipe the output from pp to compiler.

well...the "pipe" weill not be on the commandline it'll be internal to
the "Big Wrapper Program" I dont forsee the user EVER having to invoke the 
preprocssor or compiler seperately. Furthermore, the extra error file 
will only exist for the duration of the compile executation(compile time).
if it makes you feel better, we can do the same thing in a shared memory
area. =) 

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

I dont see any advantage to not running the preprocssor. If our code
is that fuckin slow that ppl what to just call the compiler, I think
we have more serious problems.

I guess we should stop calling it a preprocessor...
I dont look at it that way anymore..its more like a first stage
parser....then a preprocessor(at least in the C sense)

name change??


>> It also need AB distinction for the rest of the program too.
>>>> true, we need to be AB aware and the preprocessor needs to follow those rules

yes, I agree.

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

yes, we dont parse the body of the identification as seperate tokens.
We simple do <ident div token> <some text junk here of arbitary size>
<environ>|<data>|<procedutre>

basically.  Thats what we are doing... =)


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

dont hurt yourself. =)

But I look forward to your thoughts on it.

later,
Chad

-- 
Chad Slaughter  -- slaught at umr.edu
<PGP public key available upon request>

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