Front page | perl.perl6.internals.api.parser |
Postings from November 2000
In message <20001128003154.A30145@pembro33.pmb.ox.ac.uk>
Simon Cozens <simon@cozens.net> wrote:
> I doubt it; I get the feeling that what Dan is talking about is infinite
> look-*behind*. Nine times out of ten, you won't need to redo your parsing,
> so having an infinite lookahead will just slow everything down.
I didn't say that having infinite lookahead was better than allowing
backtracking. I simply said that the two were equivalent and that any
problem that can be solved by one can be solved by the other.
> sub bar { ... }
> print foo bar();
>
> Now, having parsed this far, we know that foo is a filehandle that we're
> printing to, so we build up our op tree to print the results of calling bar()
> to a filehandle called foo; ooh, but what do we see now:
>
> sub foo { ... }
>
> Eek, foo was actually a subroutine, and we mean print(foo(bar())); need to
> redo our parse tree. That's when the lookbehind comes into play.
That's quite a nasty example for a number of reasons. Firstly you
might have to back up and reparse a very large amount of code as the
subroutine definition could be a very long way away from the print
statement.
Secondly in order to know that you needed to back up you'd have to
remember that you hadd had to guess that foo was a filehandle but
that it might also be a subroutine and it raises a whole serious of
questions about what other similar things you might need to remember.
Tom
--
Tom Hughes (tom@compton.nu)
http://www.compton.nu/
...Would you buy a Pontiac from this, er, man?
Thread Previous
|
Thread Next