> Obligatory perl comment - TIMTOWTDI, and sometimes, a good way, > regards both clarity and speed, is having perl read a BNF and write a > parser in prolog, which does the parsing, and writes an AST in perl, > which is then eval()ed. Really. > _______________________________________________ > Please... explain.
Ok... Why prolog? Some parsing tasks require lots of backtracking, and prolog engines are good at this. One uses the best tool for the job. Parser generator technology generally focuses on doing a narrow range of things quite well. But if your task can't be made to land in their domain, you need to look elsewhere for less efficient but more general tools. Prolog is one such. Why generate the prolog code? Parser guts should generally not be written by hand. Why use a grammar? They can be nice descriptions of parsing tasks. Why wrap the grammar in perl? Grammar schemes generally lack good abstraction mechanisms. And don't degrade gracefully as the task diverges from the sweet spot of their parser generator. As a task becomes complex, one gets buried in cruft. With the power of perl there to massage things, not only can one have a clearer, much more concise and declarative description of the intended parser behavior, but one can deal with weird cases by simply saying "be weird here", rather than having them inflexibly and unrobustly threaten the entire parser organization. And if your parsing task does turn out to be doable by a specialized tool, perl can be a great way to generate it's inevitably idiosyncratic grammar. Why have an AST? It's a nice flexible way to do things. Why return it to perl? Perl can be a nice place to work. Why have prolog write perl code? A good general rule when language X is talking with language Y is for X to speak Y code and Y speak X. Languages tend to have optimized reading their own code, and writing anything. But why use eval() as the communication mechanism? Simplicity, speed, and raw power. I think that about covers it. An example application is parsing _un_preprocessed C code - macros, #ifdef's, type/identifier ambiguities and all. Cheers, Mitchell _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
