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

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

(Chad asked me to repost this to the list because he only sent it to
me.. Tim)

Tim Josling wrote :>

>Chad Slaughter wrote:
>> Tim,
>I agree. As they say, we are mostly in violent agreement.

yep. =)

>In practical terms I think we agree. The end of the line is the right
>margin, 
>unless it is longer than 2**32.

correct.

>> 
>> setup the ability to generate listings.  =)
>- so we need to keep the info somehow.

*twitches violently* yeah, somehow. Any ideas, anyone?
I worked on this problem over lunch...I didnt like it. =P
(the problem, not lunch =)*

>newlines within character strings...

>So I need some way to handle this problem.

>Example

>  01 filler "blahblahblah?blah".
>(the ? above represents the EBCDIC newline character). 

>After transliteration, this comes out as 

>  01 filler "blahblahblah
>blah".
>>>> error invalid continuation of non-numeric literal".

>So my solution would be 
>  01 filler "blahblahblah\nblah".
>OR
>  01 filler "blahblahblah\x0ablah".
>Then the compiler needs to recognise the escape sequences (optionally).

well, then we are once agian. In total agreement.
Save, for literal strings...just encode them in hex...adn the
compiler shouldnt care. Only the runtime system.

>I would expect that after conversion to ascii, the user may want to edit
>on the 
>PC/Unix box, so they would see this. In other words they may want to
>convert 
>the ebcdic once and for all as a standalone operation.

ok, I get it. WE have two problems here.
One: what to do with the char encoding for a compiler
Two: Migration of source code.

I am now ONLY working on the first one. This is not a migration tool.
Its a tool to turn programs written in COBOL into binary executables.

Now the fact, we have an intermediate text format, is irrelevent.
The issues with source code migration are different from our goals.
If we wish to change them, then thats fine. But I am not writing a
migration tool, and as such I will make no allowance to that end.
To do so, I feel, would be detremental to our goals and add unneccesary
complexity to our all ready difficult task.

Now, if we wish to create a migration tool seperatly from the compiler,
then
fine. 

This is the same reason I do not generate human readable C code. It is
not designed for human consumption.

>See 4.2 where it says the fullstop is only a separator if followed by a

Ok thanks for the reference. I'll read thru it tonight.

>> 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.
>> 
>The IBM compiler listings do show the output of the COPY/Replace in the
>listing, so 

ok copy adn replace are a very special case. Since the program is not
even legal Cobol until after copy adn replace are ran. I do not consider
the src text after a copy/replace to be intermediate as such.

I am thinking more of C code and the pseudo-code after the complete
preprocessor run(ie after copy/replace run. 

>the user can see did it do what they expect, otherwise they are flying
>blind.
>I would like to be able to empower the user to diagnose as many problems
>as they can.

Also, I think this issue needs to be put on hold. As I dont think we
ahve 
ever discussed how to go about doing a listing. Either abstractly or
concreatly..nor even thought about how to get it into the whole compiler
process.
SO I guess thats the next topic to discuss. =)

>>>>
>I don't have a copy of the current source - can anyone help!

You mean the phase II stuff? if so, you dont want it. 
THe Phase II stuff as it currently stands has been effectivly nuked.
I am mainly talking about the netrexx/java code. 
The non-java parts are still there, mainly dealing with the runtime
libraries.


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.