More Basics

Hello,


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


    Also, top down RDPs seem MUCH more intuitive to me then bottom up
parsers like yacc (Hehe..After all, we're taught to code top-down, so
it becomes second nature :-) ). RDPs appearently handle actions
embedded within a rule more 'cleanly' then yacc-like parsers and
generate more 'human readable' code. So why did bottom up LALR(1)
parsers seem to become the 'standard' ?? Was it purely an effeciency
thing (I could see that being an issue on the computers in use 20
years ago...) or is there something that bottom up parsers don't do as
well ?? (smaller set of allowable grammars,etc ??)


(Uggh...please excuse the spelling..DejaNew's spell checker is useless :-/ )


Thanks Again
Steve
[LALR can take longer to wrap your brain around, but it can parse a
larger set of languages than LL(1), so in most cases you don't have to
twist the language around as much to make it fit the tool. I agree
that newer LL tools like PCCTS have closed the gap considerably. Re
math and set theory, there's not much away around it if you want to
understand how parsers work. -John]
--

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