On Fri, 24 Nov 2000, Nicholas Clark wrote:
> I think Dan was suggesting that the (user side) regex doesn't change at all
> (so that's no new syntax there)
> It's just that the innards of perl gains a tied scalar that doesn't actually
> read in and buffer the file immediately, but defers it as long as it can get
> away with. And that the regex engine knows about these lazy scalars and
> provokes the read-more when needed.
Right. And I was suggesting that while this might solve our problem it
wouldn't do much for all the other people that have to solve the same
problem. I'd like to see a general solution accessible from Perl. If
that solution is some tied-scalar magic, fine. If it's more involved than
that (and I think it will be) then we'll need to think about the syntax a
bit.
> I don't think that this differs from the current parser. If it encounters
> open " but never a close ", it will read and buffer to the end of file
> before realising that there's a problem. (because strictly there isn't
> a problem until EOF is encountered before the closing ")
>
> I'm not certain there's anything that can actually be done to avert the need
> to buffer a lot of script in these situations. You mustn't attempt to seek
> the script file handle as it might be from something unseekable such as a
> pipe (or socket. BEGIN {socket STDIN...})
I suppose that's true. I was immagining something less extreme than the
absolute failure case of missing a closing ". I'm imagining a failure
that is recoverable but still requires running the regex to the end of the
"string" to find that out. Are there any like this? Perhaps not.
Perhaps this just isn't a reasonable criticism of regex parsers since
normal parsers do it all the time anyway!
-sam
