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

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

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

well, I completely over looked that word in your mail. sorry. =)

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

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]

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

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. 


>The utilities fix this up (convert to ASCII, add \n every 80 characters, 
> optionally
>remove cols 1-6, remove cols 73-80,

yes, I think this should maybe be two utilities one to check the ibm 72 format
and strip the crap out another to do the ebcidic conversion..
I am thinking there already is a std tool to do the ebcidic conversion...

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.


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

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. Convert all the character
strings to maybe just hex characters or somehting.
But I am just guessing, I am not sure I understand the problem enough
to comment..but like that ever stops me. =)

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

yes. gcc is simple a "Big Wrapper Program" [tm] Which handles all 
the commandline flags and stuff like invoking the linker, and the 
preprocessor, etc
So well have a "main" that allows someone to type "cobol file.cbl"
and have an execuatable created. But they can also do stuff like 
create seperate object modules that can be "linked" to an
final execuatable.

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

>The comments in the code do refer to this - I think it is a good idea. 
> The userdoc
>will also.
user docs? what are those? ;)

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

no, I understand why copy/replace are part of the preprocessor/ i never 
said they shouldnt be. I was saying you might want to hang off on them just
yet. But ignore that.

>everything at once is too hard for me, especially given how messy 
> continuations,
>comment-entries, adding spaces to end of lines, etc all are.

what do you mean everything at once? everything in the preprocessor?
what we've talked about shouldnt be too much for the preprocessor, save
the copy and replace semantics which are kind of intense.

or do you mean handling all of cobol in one parser? yes, that is true. =)


>I was just looking to follow the practice of the C compiler and C 
> preprocessor, lex

ok. I am not demaning what you are thinking. For I thought the exact 
same thing when we started out. But I have since learned that Cobol and C
are completly different and to attempt to transpose the C way of doing
things on to cobol will not work.
Now you can take that at face value. or you can question it. Its based on
experience of about 18+mos working on this problem and trying to resolve
those difference. I finally gave up and approached cobol from a new way.
As Xp points out. Do the simpliest thing possible that works.
In this case thinking it was like C was easy, until you realize it
doesnt work.

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

>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

I disagree. I think i lookup file is the simplest thing to do. 
But then again I am not sure. I dont like adding shit for the main parser
to do. as its job, is already too hard. 

>preprocessor, and if in the compiler if the customer bypassess the 
> preprocessor.

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.

I am not trying to shoot down your ideas. I like your line of thinking.
I am trying to push you quickly down the path we have travel in hopes
that you can learn from our experience without having to take the trip
your self. 
This is not to say that what we thing the experience says, is correct.
But maybe you have some insights about this "experience".
I am rambling now. I liek your thinking, keep it up. Ignore waht I said. =)


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

>output things in the correct columns. In '95 the AB rules go away, so it 
> should be

well, we are doing 85 so we need to check area A, B compatiblity.
ANd it will be a option. The user will be allowed to use
the either free format or fixed column format.

>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 

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.

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

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

yes, the symbol table is a very big point of dependency between the
"partitions".

Als, I guess I missed teh discussion about compilers on wiki. if you
have the page, please pass it along.

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.