On Tue, Aug 10, 2010 at 9:00 PM, wrote:
> Once the & operator is in rakudo, though... I gather I /could/ do something
> like the following
>
> ^ [ * & ] $
>
> And this would in effect ensued that the sequence "abc" doesn't exist
> anywhere across the match for
>
>
> Is this correct?
>
Not
Back to your original advice...
> If you want to match an alphabetic string which does not include 'abc'
> anywhere, you can write this as
>
> ^ [ ]* $
I presume this only works here because is one character... if instead
of I used anything more complicated
(for example)
token name
{
philippe.beauch...@bell.ca wrote:
> On the & operator... are you saying that it would operate basically as
> expected...
> allowing sets of rules and'ed rather than or's with the | ?
Yes, with the limitation that both parts separated by & have to match
the same length of string, so that for exam
he | ?
--- Phil
-Original Message-
From: Moritz Lenz [mailto:mor...@faui2k3.org]
Sent: August 10, 2010 2:09 PM
To: Beauchamp, Philippe (6009210)
Cc: perl6-language@perl.org
Subject: Re: regex and
Hi,
philippe.beauch...@bell.c
Hi,
philippe.beauch...@bell.ca wrote:
> rule TOP
> {
> ^
> [
> & *
> &
> ]
> $
> }
The & syntax is specced, but it's not yet implemented in Rakudo.
But note that is a zero-width assertion, so your e
On Wed, 5 Jun 2002 [EMAIL PROTECTED] wrote:
> Just read (skimmed) apocalypse 5, had one concern - it looks like we are on a
> serious collision course with parsing the various *mls.
>
> before:
>
> m#..etc#
>
> after
>
> m#\\\#
>
> Also, the space being backslashed sort of bugs me. Surely th
--
On Wed, 5 Jun 2002 13:21:39
Brent Dax wrote:
>[EMAIL PROTECTED]:
># Just read (skimmed) apocalypse 5, had one concern - it looks
># like we are on a serious collision course with parsing the
># various *mls.
>#
># before:
>#
># m#..etc#
>#
># after
>#
># m#\\\#
>
>That's intentiona
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#..etc#
#
# after
#
# m#\\\#
That's intentional. What will that regex do with this?
That's interpreted
Michael G Schwern wrote in perl.perl6.language :
> On Tue, Apr 23, 2002 at 11:11:28PM -0500, Me wrote:
>> Third, I was thinking that having perl 6 regexen have /s on
>> by default would be easy for perl 5 coders to understand;
>> not too hard to get used to; and have no negative effects
>> for exi
> when matching against something like "foo\nwiffle\nbarfoo\n"
>/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
>/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?
On Tue, Apr 23, 2002 at 11:11:28PM -0500, Me wrote:
> Third, I was thinking that having perl 6 regexen have /s on
> by default would be easy for perl 5 coders to understand;
> not too hard to get used to; and have no negative effects
> for existing coders beyond getting used to the change.
I'm ju
> > : I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of "match anything but
newline" into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor s
> : I'd expect . to match newlines by default. For a . that
> : didn't match newlines, I'd expect to need to use [^\n].
>
> But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then whe
On Tue, 2002-04-23 at 12:48, Larry Wall wrote:
> Brent Dax writes:
> : # \talso
> : # \nalso or (latter matching
> : logical newline)
> : # \ralso
> : # \falso
> : # \aalso
Brent Dax writes:
: Sorry to reply to the same message twice, but I just noticed something.
:
: Larry Wall:
: # {n,m}
:
: Isn't that the only use of angle brackets as a quantifier? That's going
: to make parsing more difficult...
How so? It's just a one-character lookahead to s
Me writes:
: > /pat/i m:i/pat/ or // or even m ???
:
: Why lose the modifier-following-final-delimiter
: syntax? Is this to avoid a parsing issue, or
: because it's linguistically odd to have a modifier
: at the end?
Haven't decided for sure to lose it, but it does have several problems.
Fir
Sorry to reply to the same message twice, but I just noticed something.
Larry Wall:
# {n,m}
Isn't that the only use of angle brackets as a quantifier? That's going
to make parsing more difficult...
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen C
Aaron Sherman writes:
: On Mon, 2002-04-22 at 21:53, Larry Wall wrote:
:
: > * Parens always capture.
: > * Braces are always closures.
: > * Square brackets are always character classes.
: > * Angle brackets are always metasyntax (along with backslash).
: >
: > So a first whack
Brent Dax writes:
: # ?pat? // or even m ???
:
: Whoa, those are moving to the front?!?
The problem with options in general is that they can't easily modify
parsing if they come in back. Now in the particular case of /f and /i,
it probably doesn't matter. But I was trying
On Tue, 2002-04-23 at 04:32, Ariel Scolnicov wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > /pat/x /pat/
>
> How do I do a "no /x"? I know that commented /x'ed regexps are easier
> reading (I even write them myself, I swear I do!), but having to
> escape whitespac
On Wed, 24 Apr 2002, Iain Truskett wrote:
> * Larry Wall ([EMAIL PROTECTED]) [23 Apr 2002 11:56]:
>
> [...]
> > * Parens always capture.
>
> Maybe I missed something in the rest of the details, but is anything
> going to replace non-capturing parens? It's just that I do find them
> quite us
* Larry Wall ([EMAIL PROTECTED]) [23 Apr 2002 11:56]:
[...]
> * Parens always capture.
Maybe I missed something in the rest of the details, but is anything
going to replace non-capturing parens? It's just that I do find them
quite useful.
--
iain.
> # =~ $re =~ /<$re>/ ouch?
>
> I don't see the win.
Naturally =~ $re is a bit cleaner, but we can't do that because =~ is
smart match, not regex match.
> # (?=...)
> # (?!...)
> # (?<=...)
> # (?
>
> Cute. (Wait a minute, are
On Mon, 2002-04-22 at 21:53, Larry Wall wrote:
> * Parens always capture.
> * Braces are always closures.
> * Square brackets are always character classes.
> * Angle brackets are always metasyntax (along with backslash).
>
> So a first whack at the differences might be:
[...]
>
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single
Larry Wall <[EMAIL PROTECTED]> writes:
[...]
> /pat/x/pat/
How do I do a "no /x"? I know that commented /x'ed regexps are easier
reading (I even write them myself, I swear I do!), but having to
escape whitespace is often very annoying. Will I really have to
escape all spaces (
Piers Cawley:
# "Brent Dax" <[EMAIL PROTECTED]> writes:
# > Larry Wall:
# > That's...odd. Is $$ (the variable) going away?
# >
# > # /./s // or /<.>/ ???
# >
# > I think that . is too common a metacharacter to be
# relegated to this.
#
# I think you failed to notice that '/
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Larry Wall:
> That's...odd. Is $$ (the variable) going away?
>
> # /./s// or /<.>/ ???
>
> I think that . is too common a metacharacter to be relegated to
> this.
I think you failed to notice that '/s' on the regex. In general . w
Larry Wall <[EMAIL PROTECTED]> writes:
> /^pat$/m /^^pat$$/
$$ is no longer the current PID? Or will we have to call that '${$}'
in a regex?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
Larry Wall:
# Me writes:
# : > Very nice (but, I assume you meant {$foo data})!
# :
# : I didn't mean that (even if I should have).
# :
# : Aiui, Mike's final suggestion was that parens end up
# : doing all the (ops data) tricks, and braces are used
# : purely to do code insertions. (I really li
> (?=...)
> (?!...)
> (?<=...)
> (?
> (?>...)
Yummy :)
I'd say this is about perfect. The look(ahead|behind)s, er,
look<:ahead|behind>s are used seldom enough that this is practical. And
it's I much clea[nr]er than that (?=...) crap
Me writes:
: > Very nice (but, I assume you meant {$foo data})!
:
: I didn't mean that (even if I should have).
:
: Aiui, Mike's final suggestion was that parens end up
: doing all the (ops data) tricks, and braces are used
: purely to do code insertions. (I really liked that idea.)
:
: So:
:
On Mon, 2002-04-22 at 14:18, Me wrote:
> > Very nice (but, I assume you meant {$foo data})!
>
> I didn't mean that (even if I should have).
>
> Aiui, Mike's final suggestion was that parens end up
> doing all the (ops data) tricks, and braces are used
> purely to do code insertions. (I really li
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
On Sat, 2002-04-20 at 14:33, Me wrote:
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
Very nice (but, I assume you meant {$foo data})! This does add another
special case to the regexp parser's handling of "$",
On Sat, 2002-04-20 at 05:06, Mike Lambert wrote:
> > He then went on to describe something I didn't understand at all.
> > Sorry.
>
> Few corrections to what you wrote:
>
> To avoid the problem of extending {} to support new features with a
> character 'x', without breaking stuff that might have
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by d
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is simple.
> He then went on to describe something I didn't understand at all.
> Sorry.
Few corrections to what you wrote:
To avoid the problem of extending {} to support new features with a
character 'x', without breaking stuff that might have an 'x' immediately
after the '{', my proposal is to require on
Mike Lambert:
(a bunch of stuff about regexes)
No offense intended, but I had trouble understanding that, and I helped
come up with the thing. :^) So, I'll try to interpret.
In Perl 5, we came up against the problem of simply running out of
characters in regexes. To deal with this, Larry came
40 matches
Mail list logo
