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