[CVS ci] pcre pattern match example
Leopold Toetsch
abcdef12 =~ /bc(.)([a-z]+)/
ok: 3 from 1 to 6 matched: 'bcdef'
all matched: 'bcdef'
(1) matched: 'd'
(2) matched: 'ef'
pcre.imc dynamically loads libpcre and performs a pattern match on the
commandline args given.
As its for sure useful[1] to have pattern matching available, the
questions arise:
Do we want PCRE in core?
Should it remain an external library?
If the latter, some wrappers would be handy to simplify matching and
extracting results.
[1] I'm thinking of booting the real rule machine for perl6. Other
languages are using PCRE directly or at least almost the same regex flavor.
Comments welcome
leo
Dan Sugalski
> $ parrot examples/assembly/pcre.imc "abcdef12" 'bc(.)([a-z]+)'
> abcdef12 =~ /bc(.)([a-z]+)/
> ok: 3 from 1 to 6 matched: 'bcdef'
> all matched: 'bcdef'
> (1) matched: 'd'
> (2) matched: 'ef'
>
> pcre.imc dynamically loads libpcre and performs a pattern match on the
> commandline args given.
>
> As its for sure useful[1] to have pattern matching available, the
> questions arise:
>
> Do we want PCRE in core?
No.
> Should it remain an external library?
> If the latter, some wrappers would be handy to simplify matching and
> extracting results.
Given that, for perl 5 code, we're going to have perl 5's real regex
engine, and for perl 6 in perl 5 compatibility mode PCRE is inadequate, I
don't think there's much point in PCRE as a long-term solution for
anything. Like it or not, we're going to have to reimplement perl 5's
regex compiler so it emits parrot bytecode.
Dan
Leopold Toetsch
> On Thu, 2 Oct 2003, Leopold Toetsch wrote:
>> $ parrot examples/assembly/pcre.imc "abcdef12" 'bc(.)([a-z]+)'
>> abcdef12 =~ /bc(.)([a-z]+)/
> Given that, for perl 5 code, we're going to have perl 5's real regex
> engine, and for perl 6 in perl 5 compatibility mode PCRE is inadequate, I
> don't think there's much point in PCRE as a long-term solution for
> anything. Like it or not, we're going to have to reimplement perl 5's
> regex compiler so it emits parrot bytecode.
I dunno yet, how unusable PCRE is for perl5 compat, but pcre 4.4 has
utf8 support, and even kind of ?{code} syntax called "callout".
I don't see PCRE as a long term solution but it would be a nice to have
in the meantime and it could be useful to boot the real regex machine,
be it perl5 or perl6 rules.
> Dan
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> On Thu, 2 Oct 2003, Leopold Toetsch wrote:
>
>>> $ parrot examples/assembly/pcre.imc "abcdef12" 'bc(.)([a-z]+)'
>>> abcdef12 =~ /bc(.)([a-z]+)/
>
>> Given that, for perl 5 code, we're going to have perl 5's real regex
>> engine, and for perl 6 in perl 5 compatibility mode PCRE is inadequate, I
>> don't think there's much point in PCRE as a long-term solution for
>> anything. Like it or not, we're going to have to reimplement perl 5's
>> regex compiler so it emits parrot bytecode.
>
>I dunno yet, how unusable PCRE is for perl5 compat, but pcre 4.4 has
>utf8 support, and even kind of ?{code} syntax called "callout".
The biggest issue is embedded code--it's perfectly acceptable for a
perl regex to have executable blocks in it. Not all that used at the
moment, in part because the docs for it are really bad, but it is in
there.
>I don't see PCRE as a long term solution but it would be a nice to have
>in the meantime and it could be useful to boot the real regex machine,
>be it perl5 or perl6 rules.
Fair enough, but I don't want to ship the PCRE sources, nor require
them for parrot to build, so there's something of a problem there,
unfortunately. When Arthur gets Ponie going we can just use perl's
regex engine, and we could write a perl regex compiler in pasm/pir,
but that's a bit of an undertaking.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> Fair enough, but I don't want to ship the PCRE sources, nor require
> them for parrot to build, so there's something of a problem there,
> unfortunately.
So I'll make a lib ouf of it.
Where do you prefer it to go:
* runtime/parrot/lib/
* library/
leo
Dan Sugalski
Put it in runtime, which is where I think we should be sticking all
this stuff, at least until we have a good scheme worked out for where
it should go. (We need a versioned library system at some point)
While I've no problem with a PCRE library, I want to emphasize that I
do *not* want PCRE to be required for any part of parrot's building
or configuration, any more than the ncurses stuff should be.