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 unintuitive.
>
> Ugliness is a matter of opinion, and I don't think it has a place
> here. Anyone else could simply reply, "Well, I think the =~ notation
> is beautiful and elegant, and your notation is ugly and clumsy," and
> there is no arguing with this point of view.
>
> Intuition varies from person to person. I think the proposal would be
> stronger if you would discuss some specific technical problems with
> the existing notation. Normally when we say that a notation is
> 'unintuitive' what we mean is that it works differently from the way
> people expect it to, so that they use it incorrectly. You have not
> provided any examples of how =~ is used incorrectly.
Let's say someone figured out a beautiful, terse new syntax for regular
expressions themselves. It made regexes much easier to read, though no
more or less error-prone than now. Would you throw that out? My point is
that cosmetic cleanups are significant, particularly in a language such
as perl that aims for human-grokkability.
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 for about a month (2 week vacation + intense pressure at work,
it'll never happen again, I promise!), 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.
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.
> * It performs a function that is semantically no different from
> other forms of argument passing.
>
> The same could be said for any operator, including +, and in fact some
> languages do treat + as a function whose operands are passed as
> arguments. For example, in Lisp,
>
> (my-function arg1 arg2 arg3)
>
> and
>
> (+ arg1 arg2 arg3)
>
> are syntactically identical. Since your argument here applies as well
> to +, -, ->, etc., it is not clear why your proposal is for =~ and not
> for +, -, ->, also.
True. I can't really pin down why my intuition really likes + to be
infix but gets confused by =~ being infix. Perhaps because it implies
that there's something special about binding an expression to be matched
against, and I don't see anything special about it. I like '+' because
it's standard notation from the Real World. =~ has no real world
equivalent, and in fact I don't know how to pronounce it in English so
that $x =~ /a/ makes sense. "matched against" is the best I can do,
unless it's in boolean context where "matches" works.
> I think you should add some sections to the proposal explaining what
> the benefits of your proposed change would be.
I'll add the results of this discussion.
> The other thing that I think is missing from the proposal is a
> discussion of precedence issues. For example, you did not say what
>
> /pat/ $x . $y ;
>
> would do. Is it equivalent to
>
> /pat/ ($x . $y) ;
>
> or to
>
> (/pat/ $x) . $y ;
>
> ?
Good point. I'm thinking of pretty low precedence, just above '..'. So
/pat/ $x || "abc" would be /pat/ ($x || "abc"), but /pat/ $x += 3 would
be (/pat/ $x) += 3. Or maybe a better example is /pat/ $x, 3 is (/pat/
$x), 3 instead of /pat/ ($x, 3). Your example would be /pat/ ($x . $y).
> I also worry that there may be some lexical issues lurking here.
> Are you sure that it's never ambiguous whether a particular / will
> indicate the start of a pattern match or a division operator? I would
> like to see some discussion of this.
When I have time, I'll modify perly.y and see what conflicts it comes up
with. But I'm not concerned about / being mistaken for division, since
that ambiguity already exists with bare /pat/ matches. So the left side
comes pretty much for free.
> I have several other complaints (I think you should either remove the
> wacky ideas, or treat them fully) but these are my main worries about
> the proposal.
Wacky idea == proposal that I didn't think was worth an RFC, but was
closely related to the RFC, so I figure'd I'd drop it in to see how it
fared during discussion, and eliminate or promote it depending on what
it looks like after being raked over the coals.
Generally, I regard RFCs as starting points for discussion, so v1 should
be fairly loose and suggestive. Later versions should gradually focus in
on a concrete proposal.
