On Sun, 2007-03-25 at 02:44 -0700, Erick Tryzelaar wrote: > I've written a couple small parsers before, but this one is starting to > get kinda annoying in me trying to figure out the "right" way to parse. > You guys are smart, any suggestions on how to approach this?
The dumbest way is probably the best .. purely functional is also best. I'd consider a nested parser. The top level parser and lexer just handle union djang_tok_t = | TOK_Text of string | TOK_Tag of string | TOK_Comment of string | TOK_Filter of string ; union djang_sect_t = | Text of .. | Tag of .. ... and parser just makes a list of them as the AST. Get that working first. Then in the user action code change it to return djang_sect_t object which is structured and has more detail .. which is the return type of a sub-lexer/parser for Tag or Filter (presumably comments and text remain the same -- strings). That is, call the sub-lexer/parsers in the user action codes. Note that whilst lexer functions use by parsers are generators and have state .. GLR parsers do NOT backtrack so this is cool, the parser can (and must) be purely functional, even though the input is not. Something about monadic programming: the GLR algorithm only requires input iterators, so as long as the input has only internal state (not messed with by outside world), the result remains purely functional. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
