The new pattern grammar stuff is cool. But, if Perl automatically builds the parse tree with no further work necessary by the programmer, won't that be slow? Perl can't detect that named captures (based on the subrule name) won't be used after the match succeeds, so it can't leave them out. We had all the flack about using $& and use English; when it wasn't needed, so even that one copying of the input string was an issue. Won't this stuff be orders of magnitude worse?

—John

Replies are listed 'Best First'.
Re: Perl6 regex/pattern performance issues?
by jryan (Vicar) on Sep 03, 2002 at 22:24 UTC

    No, because optimization happens as a separate step. Once the compiler realizes that named captures aren't used, it won't capture them.

    Phases aren't intertwined like perl5. Although this will slow down compilition, it will dramatically increase runtime speed, the ultimate goal.

[reply]
      Once the compiler realizes that named captures aren't used, it won't capture them.
      But that means the compiler needs to be able to solve the halting problem. Which is, for Turing Machines, unsolvable. And since Turing Machines provide a more powerful machine than any physical computer does (due to their finite memory), not even the perl6 compiler will be able to solve this.

      Abigail

[reply]
        Remember that it's only in the general case that you can't solve the halting problem. Many specific cases are easy to solve, and things can be designed to make it easier to solve those cases. In this particular case you'll note that, unlike Perl 5's dynamic scoping of the current successful match, Perl 6 makes $0 lexically scoped. That makes it pretty easy to tell how you've used $0 and its progeny within a particular block. Furthermore, the opaque $0 object is really not much more complicated than Perl 5's hidden match object. For most of the match, you've got to keep track of your state somewhere anyway. Perl 6 will undoubtedly do the same trick as Perl 5, and produce $1, $2, etc. lazily from the information.

        Named captures are really no different in that respect. The name is really representing an offset into a capture table, and no hash is ever really built, except to hold the symbol at compile time. Perl 6 also will likely escape the $& problem by using copy-on-write semantics generally.

[reply]
      If phases aren't intertwined, how can you create an input filter or new dialect of the parser? Is BEGIN going away?
[reply]
Re: Perl6 regex/pattern performance issues?
by Elian (Parson) on Sep 04, 2002 at 06:53 UTC
    Isn't it a bit premature to worry about the speed of a feature that's not even implemented yet?
[reply]
      Certainly not!
      If we discuss these features, we might change the way they are implemented. I strongly assume that a couple of the folks working on Perl 6 look into the Monastery occasionally...

      BrotherAde

      Update:
      Zaxo just reminded me to look at Elian's homenode... Ouch! (slaps self for not doing proper research first)
[reply]
      Waiting until it's implemented is TOO LATE. :)
[reply]

Back to Meditations