[GNU-COBOL] Re: GNU COBOL

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

Laura,

(hope you don't mind the cc to the list - it is relevant I think and also a way to
check I'm on it.)

Thanks for the reply. Yes please I would be very interested to see the Sabcle CC
code and/or cocom.

I have already gotten something big out of this - ExtremeProgramming. I am totally
sold and have redone all my work on COBOL so far to fit in with it. How thoroughly
do you do XP? Eg

* Unit test cases all done before coding, nothing goes in until it passes the test
cases.
* Continuous refactoring
* Do the simplest thing that can possibly work
* You aint gonna need it (build only what you need now)
* Massively parallel work. Everone can work on any piece of code. No titles like
Architect/Designer (oops).

Obviously some things are hard here:

* User stories and priorities - where do they come from?
* Programming in pairs - I think most of you are near each other but even if
geographically isolated you can do some workarounds.

Where from here? I would like top check out the recent code and also let you have a
chance to see my work. I think I will finish the preprocessor and put that up on
the Web for you to see if you like it. At the same time if you have some design
concepts and particularly scope I am keen to hear about it. My planned scope for
the preprocessor is:

1. Handle COPY verb (with unlimited nested includes as an extension).
2. Optionally Expand tabs per user specs.
3. Handle replace verb as per C85.
4. Optionally handle Ebcdic to ascii conversion and conversion of IBM 72 columns to
variable format.
5. Optionally Strip off sequence numbers
6. Splice continuations. (not supporting X/Open & continuations at the moment - is
this important?).
7. Optionally add extra spaces at end of lines so the full-stops are valid
(standard insists they have a space after them).

All but 1 and 3 are going - and fully test-cased of course -  so far.

So the compiler will get a pretty clean and simple file (probably with #line
directives in it like C preprocessor for better debug and listings).

My current theory is to use Flex/Bison and work around the limitations as they
arise. I may have this very wrong.

I am also interested in how we can achieve the 'bazaar' model of development - ie
avoiding bottlenecks - how do you partition a compiler.

Have you had a look at the cobol 95 draft - lots of changes!

Let me know your thoughts.

Regards,
Tim Josling

Laura Tweedy wrote:

> Hi Tim!
>
> Tim Josling (tej@melbpc.org.au) wrote:>
> > Not sure if you got my earlier messages. I subscribed to the mailing
> > list and sent a couple of messages to it but nothing came back to me,
> > now did anything appear on the archive.
> >
>         Yes, I got your messages.  You should be subscribed now.  There's not
> usually much traffic.
>
> > My name is Tim Josling. I started work on a COBOL compiler before I
> > heard about this work. Please subscribe me to your mailing list.
> >
> > I am at the early stages. I have written a number of utilities to
> > convert fixed format to free format etc, and I have started work on the
> > preprocessor which will do COPY, continuation lines and REPLACE.
> >
>         Excellent!  We have done some minimal work on the preprocessor, but
> got sidetracked into finding a good tool to describe the grammar and make it
> maintainable.
>
> > I am basing my work on a copy of the Cobol 85 standard, with addenda,
> > which I bought. I am trying to get the subsequent interpretations. I
> > also have the COBOL 95 preliminary spec which I have had a look at to
> > try and avoid coding myself into a corner. See www.cobol.org and links
> > from there.
> >
>         We are also working from the Cobol 85 standard.  It's my school's
> copy, so I will have to get a copy for myself when I graduate in May.
>
> > I had a look at cobcy. I am using some of it but the author is now
> > looking to rewrite using javacc from IBM.
> >
>         We also looked at that, but he does some strange things to make
> parsing easier that doesn't stick to the standard.  We are very interested in
> making an implementation that follows the standard as closely as possible.
>
> > I will be in touch again once I have had a look at the phase 1 code.
> > Would is also be possible to get a look at the phase 2 code?.
> >
>         The phase 1 code is quite messy. :)  It was written under tight time
> constraints for a semester project.  The phase 2 code is, well, very splintered
> right now.  We started work using SableCC and Java, which quickly became too
> slow and cumbersome.
>         I can give you copies of the SableCC code and/or the cocom code, both
> of which aren't even close to being useful, but are just tests for the compiler
> generators really.
>
> > Finally, one question: Why not use Flex and Yacc/Bison rather than other
> >
> > compiler generating tools. I haven't found anything yet than looks
> > impossible with Flex and Yacc.
> >
>         One of our goals was to make a grammar that was easy to read and
> maintain.  SableCC had a wonderful input syntax that separated grammar
> description from the actions, so it was *very* readable.  But, as I said, it
> was really slow, both in compile time and run time.
>         So, we are looking at "flavors" of bison that have EBNF.  Since you've
> seen the Cobol grammar, I think you'd agree that trying to describe it in
> straight BNF would be difficult in the extreme when trying to maintain
> readibility.  The program we're looking at right now is called "cocom"
> http://www.geocities.com/SiliconValley/Lab/4557/cocom.html
> which is like bison, but it's LR(k) and a complete rewrite.  It's like bison
> in that it works well with flex, which is adequate for what we need.
>         We went with SableCC not because the task looked "impossible" with
> flex/bison, but it looked difficult and hard to maintain.  But, after trying
> several different systems over the last year and a half, bison is going to be
> as easy as the other systems and it's much faster and more standard.  *shrug*
> I don't think we lost anything by trying other systems. :)
>
> > My code is GPL so we will be able to share code at least, particularly
> > the runtime code.
> >
>         Excellent!  My current task is still trying out cocom and trying to
> get multiple parsers to work.  We have considered having a seperate lexer and
> parser for the pic statement.  I will discuss this on the list later today or
> tomorrow.
>
>         Thank you for contacting me.  I always enjoy hearing about other people
> interested in Cobol and their projects.  If you would like to join our team,
> I'll put you on the web page and we can discuss the preprocessor and some
> other preprocessing tasks we've thought of.
>
> Cheers!
> laura
> --
>    .. Laura Tweedy .. tweedy@umr.edu ..


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