> : =~ has no real world equivalent, and in fact I don't know how to
> : pronounce it in English so that $x =~ /a/ makes sense.
>
> Yes, that's all pretty much on the mark.
Not true, IMO. In math, =~ is used to indicate "rough equivalence".
(Actually, the ~ goes on top of the =, but this is a mi
Nathan Torkington wrote:
>
> Nathan Wiger writes:
> >$x =~ /a/; # $x is roughly equivalent to a
>
> I've been going at high speed through this thread, but has
> anyone mentioned:
>
> m{$foo}{^baz.*bar$}i
> s{$foo}{(\w+) \1}{$1}g
>
> With th
> > eq and ne are far more confusing.
>
> Hm. I've never had problems with this, although it does confuse me to go
> back to the shell's [ ] (aka test) and have them be backwards.
Yeah, I've got them finally sorted out, it only took me about 5 years...
;-P
> >if ( $x == m/stuff/ ) { ... }
>
Nathan Torkington wrote:
>
> $foo->name . " says " . $bar->text . " hello to " . $baz->actor
>
> which isn't a win!
You'll probably like RFC 103 then. It addresses this very thing. I just
didn't stop to think that m// was just a fancy qq//.
-Nate
[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 @mul
>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 r
> =head1 TITLE
>
> Replace =~, !~, m//, and s/// with match() and subst()
In a marked oversight, I'd also like to note that tr// would be replaced
with trade:
Perl 5 Perl 6
--- --
$str =~ tr/a/b/;$new =
Nathan Torkington wrote:
>
> When I was thinking about this very topic yesterday and today, I
> came up with this problem:
>
> @strs = ();
> match /pat/, @strs; # surprise! I'm matching on $_
>
> That is, how do you tell an empty array from no arguments?
Easy: We'll just use lazy evalua
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
@
Jonathan Scott Duff wrote:
>
> I think that C is too syntactically close yet semantically far
> from C that the evil demons of confusion will rear their ugly
> heads.
I agree too, any suggestions are welcome. The fact that 'sub' and
'substr' are already taken makes this tough...
> Given the ab
Tom Christiansen wrote:
>
> There are thirteen years of precedent, not to mention the millions of users,
> who are completely accustomed to writing expressions like
>
> next if /\s+/ || /\w+/;
>
> It's nearly part of Perl's language signature. I wouldn't count
> on this going away if you s
Mark-Jason Dominus wrote:
>
> > > $count = () = $string =~ /pattern/g;
> >
> > Which I find cute as a demonstration of the Perl's context concept,
> > but ugly as hell from usability viewpoint.
>
> I'd really like to see an RFC that looks into making the following
> features more orthogonal:
Tom Christiansen wrote:
>
> How nice of you to put words in my mouth. Please cite me the precise
> message ID, date, and appropriate text in which I said "we can't
> change anything because of precedent".
First off, I wasn't trying to insult you, or push a hot button, or
suggest we should destro
Tom Christiansen wrote:
>
> But if *MOST* perl1 .. perl5 programs aren't going to work unchanged,
> that means that most people's existing perl knowledge-base will no
> longer be valid. That probably means that they aren't going to be
> able to just type in the Perl that they already know, either
Mark-Jason Dominus wrote:
>
> m/.../Count (instead of m/.../t)
> m/.../iCount (instead of m/.../it)
> m/.../Count,i (instead of m/.../ti)
> m/.../Count,Insensitive (instead of m/.../ti)
Blech, no. Please. Less typing good.
Tom Christiansen wrote:
>
> $count = getpwnam("tchrist")/l;
> $count = getpwnam("tchrist", LIST);
> $count = getpwnam("tchrist")->as_list;
>
> All of those, frankly, suck. This is much better:
>
> $count = () = getpwnam("tchrist");
Hmmm. I agree a general purpose mechanism is g
Tom Christiansen wrote:
>
> >While I agree that /l is bad, I think going through the crap of "= () ="
> >is even worse. Does it work? Yes. But is it easily usable and fun, even
> >for non-experts? No.
>
> Oh, for crying out loud--at some point, you have to stop tossing
> rotting fish for the sta
Tom Christiansen wrote:
>
> Goodness, it certainly does. It's loads easier than learning a new buzz^Wkeyword
> or a new switch, because you already know it.
Nobody with a sound mind would ever suggest that:
> $stuff = () = $r =~ /crap/shit/;
Wouldn't still work. At least not me. But these t
Jonathan Scott Duff wrote:
>
> I'll agree that /l is bad too. But I think adding a new "list"
> keyword is also bad. What about other contexts? Are we going to have
> "scalar", "list", "hash", "boolean", "string", "number", etc.? Not to
> mention (even though I am) user-defined contexts (my D
Tom Christiansen wrote:
>
> >And hashes are assembled just like lists anyways:
>
> > %hash = list get_key_vals;
> > %hash = (key, val, key2, val2); # same thing
>
> Eh? List context is conferred by the % on the LHS. You need
> no redundant listification redundancy there.
I was trying to
> tr('a-z', 'A-Z', $str)
>
> replaces a-z with A-Z, and
>
> tr($foo, $bar, $str)
>
> replaces the characters from $foo with the characters from $bar.
> No special syntax is necessary.
This is actually right up the alley of v2 of RFC 164, which I am editing
currently. Exactly, i
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 peo
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 translit
Tom Christiansen wrote:
>
> There is *nothing*wrong* with any of them, and to suggest breaking
> them is extremely demoralizing.
Agreed. 100%. But wait for the RFC, I think you'll find you might
actually like it. It doesn't break *any* of Perl 5's regex expressions.
Not one. And it adds a whole
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
> This RFC proposes a simple use for C<=~>: as a last-argument rvalue
> duplicator. What this means is that an expression such as this:
>
>$value = dostuff($arg1, $arg2, $value);
>
> Could now be rewritten as:
>
>$value =~ dostuff($arg1, $arg2);
David Nicol and I were brainstorming off
Steve Fink wrote:
>
> Hm. Larry didn't really like anything that would reverse the order of
> the pattern and the expression to be matched against, and I think I
> agree at least that it should always be possible to put the direct
> object at the beginning, preferably in a way usable by more than
Uri Guttman wrote:
>
> TC> ($this = $that) =~ s/foo/bar/;
> TC> for (@these = @those) { s/foo/bar/ }
>
> TC> You can't really do those in one step without it.
RFC 164 v2 has a new syntax that lets you do the above or, if you want:
$this = s/foo/bar/, $that;
@these = s/foo/b
Mike Lambert wrote:
>
> or even:
> @a = s/a+/a/, @a;
This is actually the native syntax from RFC 164.
> Basically, the argument is that you could theoretically do @a =~ s/a+/a/
> with QS, along with many other things. So perhaps, imo, it would be best
> to just let QS handle it.
I'm fine with t
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(>>,])/;
Eric Roode wrote:
>
> Unfortunately, as Richard Proctor pointed out, ?m is taken. Perhaps
> (?[list|of|openers) and (?]list|of|closers) ?
>
> Does that look too bizarre, with the lone square bracket in each?
> Or does that serve to make it mnemonic (which is my intention)?
Actually, I persona
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
Nathan Wiger wrote:
>
>"normal" "reversed"
>-- ---
>{__A1( )A1__}
That should be:
{__A1( )1A__}
Why you would delimit text this way I have no idea, but it could still
work...
-Nate
> 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
>
> match this with
>
> not this but
>this.
I suspect this is going to need a ?[ and ?] of its
David Corbin wrote:
>
> m:(?['' => '').*(?]):
>
> or more generically
>
> m:(?['<\w+>' => '').*(?]):
I think these are good; but I do also like the idea of "automatic
reversing" by default, since that's a common operation.
Let's combine the ideas, as Richard suggests. How about:
1. When a
> But you said "lists" up there and that sparked an idea in me ... What
> does
>
> @a =~ /pattern/;
>
> currently do? AFAICT, nothing useful.
> Also, it'd be nice if
>
> @a =~ s/foo/bar/g;
>
> did something similar.
See RFC 170, "Generalize =~ to a special-purpose assignmen
Tom Christiansen wrote:
>
> carefully consider whether any scant benefit these cutesinesses
> might provide can be truly worth further exacerbating the rampant
> inscrutability problems (stemming mainly from punctuation in lieu
> of alphabetics and from magically implicit targets, arguments, and
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
>
> ht
> RFC 145: Brace-matching for Perl Regular Expressions (Eric Roode)
>
> Nathan Wiger suggested a special syntax for matching XML-style
> open and close tags.
This died in favor of a more general brace-matching construct, ?[ and
?], which could be used in this capacity:
/(?[&#
> What's next, replace the regex syntax with something that more closely
> ressembles the rest of Perl?
No.
> Regexes are a language within the language. And not a tiny one.
I know... :-)
> So, if regexes are such a completely different sublanguage, I can see
> the m// and s/// syntax as just
> 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 actua
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 {
> 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 d
> =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
>The crux of the problem is that non-greedy qualifiers don't affect the
>"earliest match" behavior, which makes the matches more greedy than they
>really ought to be.
>
>Here is a simple example: (tested with perl 5.005_03)
>
> $_ = "";
> ($greedy) = /(b.*d)/;
45 matches
Mail list logo
