Re: More Basics and parsing Cobol

shindle@my-dejanews.com wrote:
> I'm back with more questions on basics :-) Hopefully, my questions
> will illustrate some of the problems that traditional production
> coders face when moving into parsing projects :-) With all the Y2K
> work, and source code re-engineering projects going on, there seem to
> be more and more of us having to add parsing to our 'toolbox' :-)
>
> One of the biggest problems I have is the heavy math orientation of
> existing literature. Whole chapters of the 'dragon book' were
> incomprehencable due to the math. (Which was a great blow to my ego
> :-) But I forgot the little calculus/set theory I learned YEARS ago
> :-) ) Holub's book ("Pratical Compiler Design in 'C' ??) was MUCH more
> understandable to me. Are their any other books written in this style
> that me help me ??


My comment would be that if you are working with legacy languages, you
do not really want to build a parser, you want to buy from somebody
else (proof by analogy: if you write programs in Cobol, is it required
that you write a Cobol compiler too?).


What I see in the reengineering business now is a lot of patchy Cobol
parsers cooked up by fresh students of Yacc and Lex or other similar
technologies.


If these people are good, they finally learn that Cobol parsing is too
damn complicated, that language is too huge and whoever wrote the
standard did not take parser writers in consideration (do you consider
language whose grammar takes 6,000+ lines complicated or simple?, what
about 20 distinct dialects that are not really compatible?).


If they are really good, they find that actually Yacc is not enough to
parse Cobol, because the grammar has lookaheads of more than 1.


But by that time they already spent considerable time and money on
learning these facts and Year 2000 (or whatever it is) got closer.


Following this line of reasoning, my company decided to sell Cobol
reengineering toolkit named CobolTransformer that has a good parser
and code generator with decent APIs. The rest, as we all know, is
tree walking, which is relatively simple.


The new version 3.1 of CobolTransformer (to be released in 2 weeks)
will be packaged as executable that can send the tree in and out in
externalized form, so the conversion app language does not matter. We
use C++, but any language can be used as long as you have
externalizer/deexternalizer functions. Java, C, Perl, Cobol, you name
it.


The issue of price: working toolkit has to be expensive, if it really
is a *working* toolkit, because it has a lot of hard labour invested
in it.


And also it is cheap, if you compare it to doing the thing
yourself. $10-15K for a complete toolkit may seem like a lot of money,
but if you compare it to $150-$250K in developers time if done
in-house, it looks cheap.


BTW, if anybody's interested, please checkout http://www.siber.com/sct
for more info.


Regards,
Vadim Maslov
Siber Sytems
[Despite the obvious self-interest here, this is a good point. If you
don't know how hard to expect a compiler project to be, it'll probably
be considerably harder than you expect. -John]




--

Return to the comp.compilers page.
Search the comp.compilers archives again.