Yacc ?

[Jeff Dyer]

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: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-
> bounces at mozilla.org] 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
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss