Adam Kennedy writes: > Getting (finally) to perl6, I could have sworn I saw an RFC early on > which said "Make perl6 easier to parse". > > But it would appear the opposite is occurring. Source filters have > become grammars and will now be officially approved and acceptable > (yes?) while so far as I can tell the problem of prototype vs > operator/operand interaction is not being addressed. (I'm a little in > the dark here, perhaps it is and nobody has noticed enough)
Let's say you want to write a yacc grammar to parse Perl 6, or Parse::RecDescent, or whatever you're going to use. Yes, that will be hard in Perl 6. Certainly harder than it was in Perl 5. However, Perl 6 comes packaged with its own grammar, in Perl's own rule format. So now the quote "only perl can parse Perl" may become "only Perl can parse Perl" (And even "only Perl can parse perl", since it's written in itself :-). Perl's contextual sensitivity is part of the language. So the best you can do is to track everything like you mentioned. It's going to be impossible to parse Perl without having perl around to do it for you. But using the built-in grammar, you can read in a program, macros and all, and get an annotated source tree back, that you could rebuild the source out of. You could even grab the comments and do something sick with them (see Damian :-). Or better yet, do something that PPI doesn't, and add some sub call around all statements, or determine the meaning of brackets in a particular context. The question of whether to execute BEGIN blocks is a tricky one. Sometimes they change the parse of the program. Sometimes they do other stuff. All you can hope for is that people understand the difference between BEGIN (change parsing) and INIT (do before the program starts). I love PPI, by the way :-) Luke
