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
Tom Christiansen writes:
> I'm just a bit concerned with the general notion that functions would under
> some circumstances trigger in qq guys. It's a bit odd to explain that
> things like abs() for $n+3 won't work, but $o->foo() would. Then again,
> it's already curious with $a[$n+3]. :-)
Var
>Solve the larger problem: permit method calls in qq() strings.
You mean outside of @{[ ... ]}, eh? :=},
I think Larry *might* have said something about making this work.
I'm just a bit concerned with the general notion that functions would under
some circumstances trigger in qq guys. It's a b
Nathan Wiger writes:
> But one thing that would be cool is supporting full functions in the
> left side of a pattern:
>
>$string =~ m/$r->getpattern/ie;
>
> Now that would be cool.
Solve the larger problem: permit method calls in qq() strings.
Nat
> > 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:
>
> 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 the first part of m{} and s{} containing an ex
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 the first part of m{} and s{} containing an expression.
We lose !~ there, though.
Thoughts o
Nathan Wiger wrote:
>
> > : =~ 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 ~ go
Larry Wall <[EMAIL PROTECTED]> writes:
> Mark-Jason Dominus writes:
> : It may turn out that the new notation really does have exactly the
> : same ambiguities, but that's not clear to me now. All I said was that
> : I would like to see some discussion of it.
>
> Operator vs term processing wou
> : =~ 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
> The mythical (and insistent) 'in' operator to rescue?
I don't think so. "In" doesn't mean "matches".
>$pattern in @expr
any(@expr) =~ $pattern
all(@expr) =~ $pattern
>@pattern in $expr
$expr =~ any(@pattern)
$expr =~ all(@pattern)
>@pattern in @expr
any(@expr) =~
> Collected ideas (mostly not my own):
>
> EXPR /pattern/
> EXPR m/pattern/
> /pattern/ EXPR
> m(EXPR)/pattern/
> /pattern/->(EXPR)
> EXPR<-/pattern/
> EXPR<=/pattern/
> EXPR ~ /pattern/
> match(/pattern/, EXPR)
> EXPR ? /pattern/
The mythical (and insistent) 'in' operator to rescue?
$p
>But I agree that such examples would certainly make a better argument.
>The only concrete thing I can come up with is that I and several other
>perl coders I know had a lot of trouble remembering the =~ symbol. I've
>been a very frequent perl user for about 8 years, and after I didn't use
>perl f
Larry Wall wrote:
>
> The problem here is that I think =~ does one thing right--it brings the
> "topic" out front. Hiding the variable to be modified clear out at the
> end of a big regex is not going to be a winner. It's bad enough that
> the /x modifier comes at the end.
>
> More generally,
Mark-Jason Dominus writes:
: It may turn out that the new notation really does have exactly the
: same ambiguities, but that's not clear to me now. All I said was that
: I would like to see some discussion of it.
Operator vs term processing would presumably treat any initial / as it
does now (in
> I'm not concerned about / being mistaken for division, since that
> ambiguity already exists with bare /pat/ matches.
Yes, but the current ambiguity is resolved from context in a rather
complicated way. Nevertheless it turns out that Perl does the right
thing in most cases. You are proposin
Steve Fink writes:
: Despite all that, I don't have strong feelings about this RFC. I just
: thought it would be an interesting idea to bring to Larry's eyes.
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
t
Mark-Jason Dominus wrote:
>
> It seems to me that there are at least two important things missing
> from this proposal.
>
> 1. There is no substantive rationale presented for why the change
>would be desirable.
>
> The only reasons you put forth are:
>
> * The syntax is ugly and unintuit
It seems to me that there are at least two important things missing
from this proposal.
1. There is no substantive rationale presented for why the change
would be desirable.
The only reasons you put forth are:
* The syntax is ugly and unintuitive.
Ugliness is a matter of opinion, and I d
19 matches
Mail list logo
