Adam Kennedy writes:
> Herbert Snorrason wrote:
> >On Thu, 25 Nov 2004 22:00:03 +1100, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> >
> >>And just after the snip you will see I qualify "parse" in this context
> >>as loading the perl in some form of DOM-type tree.
> >
> >And yet you disqualify the Perl6 rule system, with its tree of match
> >objects? What, exactly, is it that you want?
>
> What I'm after are 3 critical features.
>
> 1. You always get back out what you put in.
> $source eq serialize(parse($source)).
>
> 2. No side effects. Autrijus Tang suggests this may be workable
>
> 3. You can parse a document with broken dependencies.
> There are a myriad of these situations, such as
I'm afraid that's just not possible. And by that I don't mean "very
hard to implement". I mean impossible, in a halting problem sort of
way. Take this module:
module OrBar;
macro *infix:{'Â'} (AST $left, AST $right) {
return {
my ($le, $re) = ($left.run, $right.run);
$le * $re - ($le + $re);
}
}
And this program:
use OrBar;
print 3 Â 4;
There's no way you can not have that dependency and still parse the
program. What if the macro declaration declared it to be lower
precedence that listops?
And as far as not executin BEGIN blocks, well, you can't do that either.
A BEGIN block might execute and do the same thing as that declaration
(all declarations are just shorthands for the appropriate BEGIN blocks).
And then you can't parse without executing it.
You might be able to use whatever Parrot decides the alternative to
Safe.pm is in order to make sure nobody writes:
BEGIN { system 'cat /dev/urandom > /dev/mem' }
But, AFAICT, there's nothing else you can do. And the language isn't
going to change to solve this problem. Munging the grammar and the
operators at compile-time is simply too cool. The single feature I like
most about perl (it's very hard to decide) is its ability to execute
code at compile time... on top of everything you can do at compile time,
of course.
Or you could tell the parser not to execute BEGIN blocks, and hope that
works.
> (Imagine if you will a mod_perl syntax highlighting module for
> search.cpan.org. Should the search.cpan.org host have to _install_ every
> single one of the modules in CPAN?)
No, it'll just have to guess, as all syntax highlighters do. Chances
are, most modules aren't going to change things drastically enough to
make your syntax highlighting all wrong.
But you don't really need to parse to syntax highlight, either. You
just need to tokenize. The way the parser will be designed includes an
explicit tokenizer, and don't worry, we'll let you hook into it. In
fact, it seems PPI is more of a tokenizer than a parser, and that's much
more easily done. It's also quite easy to recover if it messes up.
Oh, I wrote this after missing your "I'd like to suspend this debate for
a week". So.... DELETED!
Luke
