Damian wrote:
>
> I once wrote a C++-based regex engine (much simpler than Perl's!)
> just like this.
>
> Knowing why a regex failed *is* invaluable when matching regexes
> against file streams, but there are more possibilities than you
> mentioned:
>
> "Failed"Did n
> I once brutalized Henry Spencer's engine into telling me when I was
> on my way to a match. This was for a UI: I wanted to be able to say
> that the input should only match this RE, and if they typed something
> that broke the match, I could beep and disallow the character.
>
On Tue, Jan 09, 2001 at 09:53:10AM +1100, Damian Conway wrote:
>
>> I once brutalized Henry Spencer's engine into telling me when I was
>> on my way to a match. This was for a UI: I wanted to be able to say
>> that the input should only match this RE, and if they typed something
>
Branden wrote:
> I read your RFC 93. It mentions using a sub to read from the
> string. I just think it uses the sub in two conflicting ways, one
> for requesting more data from the stream and other for telling
> there was a match.
It's really using the sub as a interface to whatever
Damian Conway wrote:
>
> Branden wrote:
>
>> Then, what you proposed in RFC 93 through
>>
>> sub { ... } =~ m/.../;
>>
>> could be handled by
>>
>> my $mymatch = MyClassForMatchingFromFileHandles->new($myhandle);
>> $mymatch =~ m/.../;
>
> This is an
Damian Conway wrote:
> # As Branden proposes:
>
> package From_STDIN;
>
> sub new { bless $_[1], $_[0] }
>
> sub MORE_DATA { $_[0]->getn($_[1]) }
> sub ON_FAIL { $_[0]->pushback($_[1]) }
>
> use overload "=~" => 1;
>
> package main;
>
> From_STDIN->new($fh) =~ /pat/;
>
>
>H. Potential
> The only thing I remark is that I believe all of Perl should be the
> most exposed possible, so that unseen levels of introspection
> can be achieved. In that philosophy I wrote my idea about
> exposing the engine's guts.
I'm well-known as a non-delving-into-the-guts type of guy. I
On Mon, Jan 08, 2001 at 05:02:17PM -0600, Jarkko Hietaniemi wrote:
> Wouldn't an incremental on-demand engine be much
> more flexible and optimizable (e.g. finding 'the fast path' smells
> like input-driven LRU to me)?
Umm, I'm not certian that I'm completly following here. It seems that in
the v
