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.
Piers Cawley:
# Brent Dax [EMAIL PROTECTED] writes:
# Larry Wall:
# That's...odd. Is $$ (the variable) going away?
#
# # /./s /any/ or /./ ???
#
# I think that . is too common a metacharacter to be
# relegated to this.
#
# I think you failed to notice that '/s' on
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 (or
/pat/i m:i/pat/ or /?i:pat/ or even m?i:pat ???
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 --
On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
Perl 6 will try to avoid synonyms but make it easy to declare them. At
worst it would be something like:
my sub operator:now ($a,$b) is inline { $a but $b }
I see your point, and it makes sense, but how will precedence work? What
would
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:
[...]
# =~ $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.
# (?=...) before: ...
# (?!...) !before: ...
# (?=...)after: ...
# (?!...)
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 useful.
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 whitespace is often
Aaron Sherman writes:
: On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
:
: Perl 6 will try to avoid synonyms but make it easy to declare them. At
: worst it would be something like:
:
: my sub operator:now ($a,$b) is inline { $a but $b }
:
: I see your point, and it makes sense, but
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
Precedence is set with the like' property:
my sub operator:now ($a,$b) is like(but) is inline { $a but $b }
sub operator:also ($a,$b) is like(and) is inline { $a and $b }
OK, but that limits you to the, um, 24 standard levels of
Brent Dax writes:
: # ?pat? /?f:pat/ ???
: # /pat/i m:i/pat/ or /?i:pat/ or even m?i:pat ???
:
: 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
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 at
In reply to Buddha Buck [EMAIL PROTECTED]:
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
Precedence is set with the like' property:
my sub operator:now ($a,$b) is like(but) is inline { $a but $b
}
sub operator:also ($a,$b) is like(and) is inline { $a and $b }
OK, but that
Me writes:
: /pat/i m:i/pat/ or /?i:pat/ or even m?i:pat ???
:
: 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
At 01:12 PM 04-23-2002 -0400, [EMAIL PROTECTED] wrote:
24 levels of precedence should be enough, else you can always resort to
parens.
I would have agreed, except that I would have also said that the 14
precedence levels of C should be enough as well -- yet we seem to have
discovered uses
Buddha Buck writes:
: At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
: Precedence is set with the like' property:
:
: my sub operator:now ($a,$b) is like(but) is inline { $a but $b }
: sub operator:also ($a,$b) is like(and) is inline { $a and $b }
:
: OK, but that limits you to the,
At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
Precedence is set with the like' property:
my sub operator:now ($a,$b) is like(but) is inline { $a but $b }
sub operator:also ($a,$b) is like(and) is inline { $a and $b }
OK, but that limits
Brent Dax writes:
: Sorry to reply to the same message twice, but I just noticed something.
:
: Larry Wall:
: # {n,m} 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
On Tue, 2002-04-23 at 12:48, Larry Wall wrote:
Brent Dax writes:
: # \talso tab
: # \nalso lf or nl (latter matching
: logical newline)
: # \ralso cr
: # \falso ff
: # \a
Larry said:
I haven't decided yet whether matches embedded in
[a regex embedded] closure should automatically pick
up where the outer match is, or whether there should
be some explicit match op to mean that, much like \G
only better. I'm thinking when the current topic is a
match state, we
: 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 when
: 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
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
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.*?)$$/
25 matches
Mail list logo
