> I'm trying to stick to a general philosophy of what's in a reg-ex, and I can
> almost justify assertions since as you say, \d, ^, $, (?=), etc are these
> very sort of things. I've been avoiding most of this discussion because
> it's been so odd, I can't believe they'll ultimately get accepted.
In <[EMAIL PROTECTED]>, Tom Christiansen writes:
:>I consider recursive regexps very useful:
:>
:> $a = qr{ (?> [^()]+ ) | \( (??{ $a }) \) };
:
:Yes, they're "useful", but darned tricky sometimes, and in
:ways other than simple regex-related stuff. For example,
:consider what happens if you
>I consider recursive regexps very useful:
>
> $a = qr{ (?> [^()]+ ) | \( (??{ $a }) \) };
Yes, they're "useful", but darned tricky sometimes, and in
ways other than simple regex-related stuff. For example,
consider what happens if you do
my $regex = qr{ (?> [^()]+ ) | \( (??{ $regex })
i keep parsing the subject of this rfc as 'ban perl books'
:)
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/per
In <[EMAIL PROTECTED]>, Bart Lateur writes:
:On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
:
:>Remove C, C and friends.
:
:I'm putting the finishing touches on an RFC to drop (?{...}) and replace
:it with something far more localized, hence cleaner: assertions, also in
:Perl code. That
In <005501c027eb$43bafe60$[EMAIL PROTECTED]>, "Michael Maraist" writes:
:As you said, we shouldn't encourage full-fledged execution (since core dumps
:are common).
Let's not redefine the language just because there are bugs to fix.
Surely it is better to concentrate first on fixing the bugs so th
> There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or
> assertions would be the only reason why I'd expect to be able to execute
> perl code every time a part of a regex is succesfully parsed. Simply
> look at RFC 197: a syntactic extension to regexes just to check if a
> number
On Tue, 26 Sep 2000 13:32:37 -0400, Michael Maraist wrote:
>
>I can't believe that there currently isn't a means of killing a back-track
>based on perl-code. Looking through perlre it seems like you're right.
There is, but as MJD wrote: "it ain't pretty". Now, semantic checks or
assertions wou
> On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
>
> >Remove C, C and friends.
>
> I'm putting the finishing touches on an RFC to drop (?{...}) and replace
> it with something far more localized, hence cleaner: assertions, also in
> Perl code. That way,
>
> /(?
> would only match integ
On 25 Sep 2000 20:14:52 -, Perl6 RFC Librarian wrote:
>Remove C, C and friends.
I'm putting the finishing touches on an RFC to drop (?{...}) and replace
it with something far more localized, hence cleaner: assertions, also in
Perl code. That way,
/(?
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Ban Perl hooks into regexes
>
> =head1 VERSION
>
> Maintainer: Simon Cozens <[EMAIL PROTECTED]>
> Date: 25 Sep 2000
> Mailing List: [EMAIL
From: "Simon Cozens" <[EMAIL PROTECTED]>
> > A lot of what is trying to happen in (?{..}) and friends is parsing.
>
> That's not the problem that I'm trying to solve. The problem I'm trying
> to solve is interdependence. Parsing is neither here nor there.
Well, I recognize that your focus was no
From: "Hugo" <[EMAIL PROTECTED]>
> :Remove C, C and friends.
>
> Whoops, I missed this bit - what 'friends' do you mean?
Going by the topic, I would assume it involves (?(cond) true-exp |
false-exp).
There's also the $^R or what-ever it was that is the result of (?{ }).
Basically the code-like
> On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote:
> > I think the proposal that Joe McMahon and I are finishing up now will
> > make these obsolete anyway.
>
> Good! The less I have to maintain the better...
Sorry, I meant that it would make (??...) and (?{...}) obsolete, no
On Mon, Sep 25, 2000 at 04:55:18PM -0400, Michael Maraist wrote:
> A lot of what is trying to happen in (?{..}) and friends is parsing.
That's not the problem that I'm trying to solve. The problem I'm trying
to solve is interdependence. Parsing is neither here nor there.
--
Intel engineering s
On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote:
> I think the proposal that Joe McMahon and I are finishing up now will
> make these obsolete anyway.
Good! The less I have to maintain the better...
--
Keep the number of passes in a compiler to a minimum.
-- D
On Mon, Sep 25, 2000 at 11:31:08PM +0100, Hugo wrote:
> In <[EMAIL PROTECTED]>, Perl6 RFC Librarian writes:
> :=head1 ABSTRACT
> :
> :Remove C, C and friends.
>
> Whoops, I missed this bit - what 'friends' do you mean?
Whatever even more bizarre extensions people will have suggested by now...
-
In <[EMAIL PROTECTED]>, Perl6 RFC Librarian writes:
:=head1 ABSTRACT
:
:Remove C, C and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Hugo
In <[EMAIL PROTECTED]>, Perl6 RFC Librarian writes:
:It would be preferable to keep the regular expression engine as
:self-contained as possible, if nothing else to enable it to be used
:either outside Perl or inside standalone translated Perl programs
:without a Perl runtime.
:
:To do this, we'll
I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
> Ban Perl hooks into regexes
>
> =head1 ABSTRACT
>
> Remove C, C and friends.
>
At first, I thought you were crazy, then I read
>It would be preferable to keep the regular expression engine as
>self-contained as possible, if nothing else to enable it to be used
>either outside Perl or inside st
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Ban Perl hooks into regexes
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 308
Version: 1
Status: Developing
=head1 ABSTR
22 matches
Mail list logo
