Re: Exposing regexp engine & compiled regexp's by Branden- January 10, 2001 Quoted from http:www.perl.compub200009ilya.html,an interview with Dr. Ilya Zakharevich:>> Q: Could you describe in more detail what additional text-> handling primitives you would like to see included with Perl> What string munging operations are absent that really ought to> be included in Perl&39;s core>> A: The problem: Perl&39;s text-handling abilities do not scale> well. This has two faces, both invisible as far as you confine> yourselves to simple tasks only. The.http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg593.html Re: Exposing regexp engine & compiled regexp's by Damian Conway- January 9, 2001 > As Rick pointed out, there&39;s no problem with overloading = for an > object, in the same way it&39;s done with eq&39;, and one object&39;s > function could return either an object or a closure (a sub > reference), so that a module could even hide the details of whether > it&39;s using the object interface with the overloaded = or the new > behaviour of = with a sub lvalue.Good point. I think at this stage we&39;re violently agreeing with each other. ;-)Damianhttp://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg592.html Re: Exposing regexp engine & compiled regexp's by Jarkko Hietaniemi- January 9, 2001 On Tue, Jan 09, 2001 at 12:41:30AM -0500, James Mastros wrote:> On Mon, Jan 08, 2001 at 05:02:17PM -0600, Jarkko Hietaniemi wrote:> > Wouldn&39;t an incremental on-demand engine be much> > more flexible and optimizable (e.g. finding &39;the fast path&39; smells> > like input-driven LRU to me)>> Umm, I&39;m not certian that I&39;m completly following here. It seems that in> the vast majority of all cases, you&39;d need to compile (or at the very least,> parse)...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg591.html Re: Exposing regexp engine & compiled regexp's by Filipe Brandenburger- January 9, 2001 Damian Conway wrote: >I&39;m well-known as a non-delving-into-the-guts type of guy. I don&39;t have I totally aggree with you that delving into the guts is the last thing we, the people that use perl as a tool, want to do! The fact is that, the least we know about the internals, the better it is. But for this to be possible, we need modules that provide the functionality we need without making us deal with the rawness of perl guts. And that&39;s why I defend the exposing of the regexp.http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg590.html Re: Exposing regexp engine & compiled regexp's by James Mastros- January 8, 2001 On Mon, Jan 08, 2001 at 05:02:17PM -0600, Jarkko Hietaniemi wrote:> Wouldn&39;t an incremental on-demand engine be much> more flexible and optimizable (e.g. finding &39;the fast path&39; smells> like input-driven LRU to me)Umm, I&39;m not certian that I&39;m completly following here. It seems that inthe vast majority of all cases, you&39;d need to compile (or at the very least,parse) the entire regex. Also, you can get vast efficency gains bycompiling a regex, so you can check the...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg589.html Re: Exposing regexp engine & compiled regexp's by Damian Conway- January 8, 2001 > 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&39;s guts.I&39;m well-known as a non-delving-into-the-guts type of guy. I don&39;t havea problem with your proposal, since (as Rick points out) it can easilybe viewed as a superset of mine, and made no harder to implement (assumingwe eventually see method calls...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg588.html Re: Exposing regexp engine & compiled regexp's by branden- January 8, 2001 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;>>>Hmmmm. Potentially more flexible, but also much more ponderous.Sorry I didn&39;t include code the first time, but actually my idea is aboutmuch more flexibility than having MORE_DATA...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg587.html Re: Exposing regexp engine & compiled regexp's by Rick Delaney- January 8, 2001 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 interesting alternative. The main problem is that matching> against a blessed object already has a useful meaning in Perl: stringify> the object...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg586.html Re: Exposing regexp engine & compiled regexp's by Damian Conway- January 8, 2001 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&39;s really using the sub as a interface to whatever source of data it&39;strying to match. > I thought, too, that requesting it to return > _exactly_ the number of characters that was requested goes against > most unix...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg585.html Re: Exposing regexp engine & compiled regexp's by Jarkko Hietaniemi- January 8, 2001 On Tue, Jan 09, 2001 at 09:53:10AM +1100, Damian Conway wrote:> > > I once brutalized Henry Spencer&39;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.> > > > I was just a greenhorn then, so it coredumped. But it&39;s another use> ...http://www.nntp.perl.org/group/perl.perl6.language.regex/2001/01/msg584.html |