This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.
Hi David, "David A. Wheeler" <dwheeler@xxxxxxxxxxxx> writes: > One reason to use an LL(1) spec directly is to prove it's LL(1), as noted above. > Another reason is that typical Scheme reader implementations will > be recursive descent parsers, which are basically LL(1) also. > I found it *easy* to implement the spec in Scheme, specifically because it was LL(1). > > I don't know if a non-LL(1) grammar would be easier to read, but > such a grammar *would* require a typical implementer to hand-perform those > transformations. I fear that would inhibit, not encourage, implementations. > But maybe that's not so. These are all compelling reasons to include an LL(1) grammar _somewhere_ in the SRFI-110 document, and I agree that it should be included. However, _if_ turns out that a non-LL(1) grammar would be easier to understand, then I think that's what should be used in the actual specification. If you disagree, then consider this: if you were reading the specification of a traditional infix language, which of the following grammars would you prefer to see when you were _learning_ about the language: E -> E + T E -> T T -> T * F T -> F or: E -> T Y Y -> + T Y Y -> <epsilon> T -> F Z Z -> * F Z Z -> <epsilon> Both of these grammars have their uses. The first is better for explaining the precise grammar to humans. The second is better for helping them to build an efficient parser. Both of these tasks are important, and they should be treated separately. Regards, Mark