[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNU-COBOL] Chad's ramblings, COPY, Obsolete elements



Reading Chad's ramblings, two things came up:

1. Obsolete language elements list: you only need to provide
double character substitution if the character set does not have
the 51 Cobol characters in its character set. Using ASCII, we are
off the hook on that one.

2. Library format. Chad suggested 'ar' files. I only realised
this after I coded my library read routines. I was following the
C precedent. Here is what I did:

a) The copy file name can be a cobol word or a non-numeric
literal (this is non-standard). In either case it is a file name
(if it is a cobol word it is converted to upper case, otherwise
it is left asis). 

b) The library name, again either a cobol word or non-numeric
literal is either an environment variable or a directory name
(extension, same deal with case). If it is an environment
variable it is assumed to contain a directory name. If there is
no library name I assume the current directory. 

c) The library directory and the library file name are
concatenated together with a '/' to give the whole file name.

d) There is no concept of search path a la C libraries.

e) This can be easily changed/enhanced later on as the file IO is
in its own module and easily changed.

I don't see any good reason to have special files for the
libraries when you can provide all the needed function using the
file system. It is implementor defined how you do libraries so
this should be standard. The main problem with using special
library files is you need to run some utiility when you update a
copy library rather than just editing a file, also it makes life
more complicated for people who use make, etc.

*******

I ran into more problems with the COPY verb using bison due to
the non-LALR(1) nature of the reference modification structure,
which can be present after function calls and in the arguments of
function calls which are valid forms of identifiers as specified
in the copy syntax. So I have a (un-)lovely kludge to scan ahead
and change token types based on what is coming. If there are a
lot of similar issues with COBOL then bison is definitely a bad
idea because this kind of thing tends to create lots of bugs (I
found several bugs even before testing it). I only have a few
hundred lines to code of the preprocessor and a few weeks of
testing. Then comes decision time on the parser - I will follow
Chad's suggestion and do a subset of the language, but I would
appreciate some suggestions on where the problem areas are. 

Did you see in the COBOL news group there is yet another effort
under way to do a free COBOL compiler. I guess as long as we all
share code and ideas it doesn't hurt (see below). I emailed Leif
but no response to date. COBOL is big - we need all the help we
can get,

Cheers,
Tim Josling

Subject: 
           Re: COBOL FAQ
       Date: 
           Sun, 16 May 1999 11:17:34 -0500
      From: 
           "Leif Svalgaard" <lsvalg@ibm.net>
   Reply-To: 
           "Leif Svalgaard" <leif@ibm.net>
 Organization: 
           IBM Global Services - Remote Access Mail & News
Services
  Newsgroups: 
           comp.lang.cobol
  References: 
           1 , 2 , 3




Thane,
I'm working on one.
When it is a bit further along, I'll open it up as an Open Source
project.

Thane Hubbell <redsky@ibm.net> wrote in message
news:373edb4f.225999439@news1.ibm.net...
> On Fri, 14 May 1999 12:40:07 +0200, Philipp Sasse
> <sasse@ont.uni-paderborn.de> wrote:
>
> >Why no word about the free Deskware Cobol interpreter availible
> >for Linux, Solaris, Mac, FreeBSD, Losedows, Aix, Irix and SCO?
> >I never used it, but I know it exists ...:
> >
> >http://www.deskware.com/cobol/cobol.htm
>
> There is the GNU COBOL project also, but the thing is billed as a
> COBOL to C Converter - not a true GNU - COBOL compiler.  If I had the
> time I would love to write a freeware COBOL compiler.  I think,
> however, that I will never have such time, nor do I have the required
> education in compiler design to do a very good job.
>


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