Re: Are lalr parse-tables viable?

Thanks For The Feedback - I Feel More Comfortable Knowing That This Is Not
Extraordinarily Large.


Torben:
> LR parse tables do tend to be rather large, so some parser generators
> use various tricks to compress the table -- the number of states and
> transitions are not changed, but the data structure used to represent
> them is smaller than the obvious two-dimensional table will be.


yes, i did not think that the 2d-array approach would have worked optimally,
so i designed a slightly more complicated data-structure which suffers a
little performace loss against a huge space saving.


> Use operator precedence declarations to resolve ambiguities
> (instead of rewriting the grammar) whenever this is possible.


this advice sadly comes too late. i wrote the grammars upfront to be lr-free
(i assumed this would be beter than converting later). unless i am missing
something, there shouldn't be any ambiguities.


> Also, if the different dialects of your language only differ in the
> names of keywords, the allowed letters in variable names and similar
> lexical details, you need only change the lexer data for each dialect
> while sharing a single parse table.


the dialects of language are very natural- orientated, so there are
significant differences in syntax. i would have liked to just swap out a set
of keywords, but this leads to some dialects suffering stilted and unnatural
structures.


Adrian:
> Doesn't sound out of line to me. If you email me your grammar I will
> run it through our tools and explain some of the phenomena that govern
> table size to you.


sounds great - i post it through now.


Chris:
> If you are parsing multiple dialects, it would not be
> surprising for the number of states to be more than that.


i am only parsing one dialect at a time. that is, the states/transitions
quoted were for the english implementation only.
the dutch and german implementations are of a very similiar order.
but only one language is loaded at a time - that is, if an "english" program
were to be parsed with the "dutch" parser, it would kick and scream errors.
(in dutch, of course...=)


much thanks for your feedback.


---
craig (at) small (minus) pla (dot) net

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