Re^2: Perl not BNF-able??

[TimToady]

Well, you can claim that Perl 6 is going whole hogger on context sensitivity than Perl 5, but the fact is that Perl 6 is cleaning up all those silly post-declarational switches you're carping about, and forcing them to be predeclarations (except for /x, which is going away entirely because it's mandatory). Left-to-right parsing is darn near mandatory in Perl 6. Lookahead dependencies are generally limited to one token. About the only exception I can think of offhand is deciding whether curlies are composing a hash or declaring a closure, and this is handled by thinking of both of them as closures, but then forcing an evaluation-time call on the closure if semantic analysis determines it's a hash composer.

As for /e, that's also gone in favor of generalized expression interpolation.

[jonadab]

Well, you can claim that Perl 6 is going whole hogger on context sensitivity than Perl 5, but the fact is that Perl 6 is cleaning up all those silly post-declarational switches you're carping about

I didn't mean to be carping. (I never considered BNF-reducability to be an interesting goal, much less an important one, for a language's development. I'm much more interested in whether Perl6 is powerful and expressive, and from what I've managed to absorb so far, it has those things in spades.) Nonetheless, now that you mention it, a number of the specific things I mentioned are indeed going away in Perl6. On the other hand, the grammar in Perl6 is mutable, so I rather doubt the Perl6 parser will be able to be 100% defined in terms of BNF, unless I'm missing something. (Which is possible. You know more about this subject than I do.)