On 4/25/13 9:23 AM, Felix S. Klock II wrote:
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to.
I'm a fan of this choice too, if only because the simplest efficient
parser-generators and/or parser-composition methodologies I know of take
an LL(1) grammar as input.
However, Paul's earlier plea on this thread ("Please don't do this
[grammar factoring] to the official parser!") raised the following
question in my mind:
Are we allowing for the possibility of choosing the semi-middle ground
of: "There *exists* an LL(1) grammar for Rust that is derivable from the
non-LL(1)-but-official grammar for Rust." ? Or do we want to go all the
way to ensuring that our own grammar that we e.g. use for defining the
syntactic classes of the macro system etc is strictly LL(1) (or perhaps
LL(k) for some small but known fixed k)?
I'm not sure we can do the latter. There are too many issues relating to
`unsafe`, `loop`, the `self` argument, etc. to make the LL(1) derivable
from the human-readable grammar in an automated fashion, in my eyes. At
least, I'm pretty sure that if we did want to go down that route, we'd
probably be doing months of parser research (and I do mean *research*,
as far as I know).
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
