Quoted from http://www.perl.com/pub/2000/09/ilya.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 inclu
> As Rick pointed out, there's no problem with overloading =~ for an
> object, in the same way it's done with `eq', and one object'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's using the ob
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'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,
Damian Conway wrote:
>I'm well-known as a non-delving-into-the-guts type of guy. I don'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
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
> 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
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
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
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
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
>
> 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.
>
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
Damian Conway writes:
> I once wrote a C++-based regex engine (much simpler than Perl's!)
> just like this.
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 the
> 1. I think it should be possible to have ``incomplete matches''.
>
> Regexp's are interpreted by a NFA, that is a state machine.
> I think it would be nice if, when I try to match a regexp against
> a string, and the string ends before the regexp matches, it
>
(*** Sorry if this is the wrong list, I think it could interest you, as it
talks about
interface with the regexp subsystem -- that's a term a read here...
***)
Hello.
I have some ideas (actually a wishlist) for the regular expression
subsystem (that's what it'll be, right?). I would appr
Hello.
I have some ideas (actually a wishlist) for the regular expression
subsystem (that's what it'll be, right?). I would appreciate if
perl6's regexp engine exposes the maximum possible interfaces, and
I'll expose why I think this would be nice.
1. I think it should be possible to have ``i
16 matches
Mail list logo
