Is $$ the only alternative, or did I miss more? I don't think I've even
seen this $$ mentioned before?
$$ is not a suitable alternative. It already means the current process
ID. It really cannot be messed with. And ${$} is identical to $$ by
definition.
I still like the idea of $$, as I
=item *
C\1 goes away as a special form
=item *
$1 means what C\1 currently means (first match in this regex)
=item *
${1} is the same as $1 (first match in this regex)
=item *
${P1} means what $1 currently means (first match in last regex)
Here's the big problem with this, and I
Simon Cozens wrote:
Looks great on scalars, but...
@foo =~ shift; # @foo = $foo[0] ?
@foo =~ unshift; # @foo = $foo[-1] ?
Yes, if you wanted to do something that twisted. :-) It probably makes
more sense to do something like these:
@array =~ reverse;
@vals =~ sort { $a =
I'm opposed to an obligation to replace m// and s///. I won't mind the
ability to give a prototype of "regex" to functions, or even
*additional* functions, match and subst.
As the RFC basically proposes. The idea is that s///, tr///, and m//
would stay, seemingly unchanged. But they'd
Mark-Jason Dominus wrote:
Larry said:
# Well, the fact is, I've been thinking about possible ways to get rid
# of =~ for some time now, so I certainly don't mind brainstorming in
# this direction.
That is in
[EMAIL PROTECTED]
which is archived at
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
I suspect this is going to need a ?[ and ?]
I think it's cool too, I don't like the @^g and ^@G either. But I worry
about the double-meaning of the []'s in your solution, and the fact that
these:
/\m[...]...\M/;
/\d[...]...\D/;
Will work so differently. Maybe another character like ()'s that takes a
list:
/\m(,[).*?\M(,])/;
Richard Proctor wrote:
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Good point.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for
Mark-Jason Dominus wrote:
RFC135: Require explicit m on matches, even with ?? and // as delimiters.
This one is along a different line from these two:
RFC138: Eliminate =~ operator.
RFC164: Replace =~, !~, m//, and s/// with match() and subst()
Which I could see unifying. I'd ask people
Mark-Jason Dominus wrote:
I think the reason this hasn't been done before it because it's *not*
quite straightforward.
Before everyone gets tunnel vision, let me point out one thing:
Accepting variables in tr// makes no sense. It defeats the purpose of
tr/// - extremely fast, known
Tom Christiansen wrote:
tr///e is the same as s///g:
tr/$foo/$bar/e == s/$foo/$bar/g
I suggest you read up on tr///, sir. You are completely wrong.
Yep, sorry. I tried to hit cancel and hit send instead. I'll shut up
now.
-Nate
if (/Time: (..):(..):(..)/) {
$hours = $1;
$minutes = $2;
$seconds = $3;
}
This then becomes:
/Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
This is more maintainable than counting the brackets and easier to understand
for a complex regex. And
Nathan Torkington wrote:
Hmm. This is exactly the same situation as with chomp() and somehow
chomp() can tell the difference between:
$_ = "hi\n";
chomp;
and
@strings = ();
chomp @strings;
Good point. I was looking at it from the general "What's wrong with how
@arrays are
[cc'ed to -regex b/c this is related to RFC 138]
Proposed replacements for m// and s///:
match /pattern/flags, $string
subst /pattern/newpattern/flags, $string
The more I look at that, the more I like it. Very consistent with split
and join. You can now potentially match on
14 matches
Mail list logo
