This decision is based on our experience that recursive descent parsers are cheaper to build and maintain than their YACC counterparts. Especially for a language whose syntax is complex and still evolving, as is ES4's. Perhaps you have experience that says otherwise.
BTW, the lexical scanner started out as an ML-LEX definition, but the tool seemed to be unable to handle a program of its size (or at least SML was unable to handle the generated tables). I wonder if we would encounter tooling issues with ML-YACC too. How portable are YACC definitions across ML implementations? Whether or not we could use it as the primary source of the reference implementation, it would be interesting to implement the current grammar using YACC to see where it is ambiguous. Regards, Jeff > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:es4-discuss- > [EMAIL PROTECTED] On Behalf Of David Teller > Sent: Monday, October 15, 2007 7:32 AM > To: JS2 > Subject: Yacc ? > > Just a simple question about the reference implementation: why is the > parser hard-coded rather than written with ml-yacc ? I admit that I'm > somewhat tired about converting this parser manually to OCaml with > bunches of regexps + human proofreading, so I'm wondering if I shouldn't > skip this and go directly to Yacc or equivalent. > > Thanks, > David > > -- > David Teller ------------------------------------------ > Security of Distributed Systems ----------------------- > -- http://www.univ-orleans.fr/lifo/Members/David.Teller > ----- Laboratoire d'Informatique Fondamentale d'Orleans > > _______________________________________________ > Es4-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
