> : =~ 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
Steve Fink wrote:
> I couldn't for the life of me
> remember whether it was ~= or =~. I've also observed one perl beginner
> look up the symbol in a book every single time she needed it for a new
> program.
all the self-assignment operators are operator, then equal-sign.
=~ is not a self-assig
> 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
Several RFCs have been issued that relate to regexes or pattern
matching but which predate the perl6-language-regex list. I have
asked the librarian to transfer ownership of these RFCs to this list.
In the meantime, here is a summary of the outstanding regex-related
RFCs:
72 (v1): The regexp en
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
12 matches
Mail list logo
