The "joys" of designing multifunctional parsers

Well, I made some major changes in my parser, most notably some more criterias for word characters and when and where to handle with EOF occurences. I don't like the current design. Mostly cause it's rather messy and can (due to it's non-regexpy quick'n dirty pattern rule mechanics) create some hopelessly endless loops you can fortunately end by calling a stop function - though it won't happen cause you can only call it in places where it doesn't really make any sense. However, I won't create a tool to detect the users faulty patterns, this is just too much work for a thing that has very well-defined syntactical contents. I don't quite know how to choose understandable names as it's structure is rather buildup on functionality than on fancy class design (I hate this lecturer so much for demanding a senselessy deep seperation) but I hope that in some days I get a better for it. I also got an interesting idea of how to combine several syntax rule sets into other rulesets, but in my first thoughts it would require very extensive dynamic type handling, which don't like in such time-consuming tasks like parsing. I'd basically split a single pattern into a marked, completely different rule set for a new parser fork. So the parser/interpreter one level above can take it's result as the desired data and interpret it as it where a random, regexp-shaped word. Quite useful approach, but I'll need to create a different system that doesn't build on dynamic type checking or heavy casting from void* to other types. Quite difficult! Well, that's something for the next term break along with a nice little multithreading toolkit. And I doubt I'll ever touch this parser I'm currently writing again since a regular expression with recursion and higher degree of abstraction is much more powerful than a "sloppy", rather specialized mufu parser for random words and repeating structures.

No comments: