Re: [GNU-COBOL] GNU-COBOL list reborn

[root <root@pobox.com>]

>>>>> "Chad" == Chad Slaughter <slaught@advancenet.net>

    Chad> Michael McKernan wrote :>
    >>  Well, this is a marvelously refreshing change for this long
    >> dormant list.  Let's hear it for the new guys!  Actually, the
    >> list is 66% larger than it was when I last checked early in
    >> September, which I'll take as a very hopeful sign.
    >> 
    >> Chad, do you really think parsing COBOL is such a bear?  I have

    Chad> I think it is. but then again I am not really into the front
    Chad> end.  I have always adn will remain in the back end by
    Chad> implementing the cobol functionality in c/c++.

Being, by nature, a back-end type as well, I'd like to see what you have
in mind.  Without intending to give offense, I'm not much interested in a
term project or proof of principle exercise, but I find the idea of
creating a production quality compiler with the expectation of having
real users pretty damned interesting.  In my most recent efforts, my team
and I managed to outperform compiled MicroFocus by a factor of two in
compute only benchmarks on several Unix/risc platforms.  I'd love to do
it again.

    >> always considered it a fairly modest part of the compiler
    >> effort, and
    Chad> funny, I have always thought of it as the hardest part. =)

It can't be too hard, it's what the computer scientists understand ;)

    >> I've always had to do it without tools.  As you may remember, I
    >> am your resident pccts champion, and I consider pccts
    >> particularly well suited to COBOL.  Did you ever apply the
    >> patches to the old grammar that I sent you a few months ago?

    Chad> yes, I do remember. No, i didnt apply th e patches myself. I
    Chad> left that up to laura, as that was her department.

    Chad> So, i cant really say, if we want to go back and look at
    Chad> pccts, then thats cool.

I seem to remember that I committed to do that this morning and since
Tim hasn't rushed to my rescue, I'll try to honor that commitment.  
The lexer and parser are not things to be done in isolation, though.
They produce the symbol table and the first intermediate form of the
program.  To be acceptable, a parser needs to be able to separate
the universe into those things that can be compiled and those things
that can be diagnosed.  A _good_ parser will, as well,  produce structures
that facilitate straightforward, efficient and minimally error prone
translation into efficient machine code.  Let's get all this stuff out
in the open, where we can stare at it.  

    Chad> What the group needs is a person to corrdinate the front
    Chad> end/ do the front end in what ever way is appropriate. as
    Chad> long as it sticks to keep with the 85 std. I think that is
    Chad> an important point. I will stick to helping corrdiate the
    Chad> back end functionality/ runtime system. as that is what I
    Chad> know best.

I'm more in favor of opening the bazaar, Chad.  When I see the first
technical food fight on this list, I'll know we're on our way.

    Chad> - -- Chad Slaughter -- slaught at advancenet.net





--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.