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

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

Chad Slaughter wrote:
> Tim,
I agree. As they say, we are mostly in violent agreement.
> 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.=)
Will try - let me know if it doesn't happen.
> 
> Mainly I am saying call the max line length, max file size. *shrugs*
In practical terms I think we agree. The end of the line is the right
margin, 
unless it is longer than 2**32.
> 
> setup the ability to generate listings.  =)
- so we need to keep the info somehow.
> 
> >> >optionally convert \n to the escape sequence "\\n").
> 
> >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...".
> 
newlines within character strings...
If you put a newline in a non-numeric literal, 
which is allowed on the mainframe which has fixed length
lines, and just transliterate that into the ascii newline character,
then the compiler
will say 'end of line with unterminated non-numeric literal. 
The newline is not 'in' the character string. 

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

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.

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

See 4.2 where it says the fullstop is only a separator if followed by a
space.
Same with commas.

Elsewhere it says that any token on a new line is deemed to be preceded
by a 
space, but it does not say any token at the end of a line is deemed to
be 
*followed* by a space.

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

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

Cheers,
Tim

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