A few days ago, one of Perl's most distinguished free-floating agents of chaos posted a patch for discussion. dots.pm changes the Perl 5 dereference arrow to a dot. This lexically scoped pragma also changes the concatenation operator from dot to tilde, which is the current syntax in Perl 6.
p5p reception tended to be positive. Discussion elsewhere tended to be
negative. After reviewing the proposal and reception, Perl
5 pumpking rjbs rejected the patch for 5.20. His reasoning is
straightforward. While fans of dots.pm may feel a legitimate
disappointment at the current rejection of the patch, it's worth praising rjbs
for an evenhanded evaluation of the intent and implementation of the feature.
(If that evaluation had gone into the smartmatch operator or automatic
dereferencing of references to aggregates with each, for example,
Perl 5 would be in better shape.)
My initial reaction to the patch was mild interest. It didn't immediately grab me as an idea that Perl needs. The more I thought about it, the less I liked it, for four reasons.
It's too invasive technically for my taste
It's a small patch to the parser, but it repeats a pattern which I've never liked in feature.pm, which is to say that it adds branches to the Perl parser/tokenizer/lexer which apply to the current compilation unit based on hints provided to the lexical scoping.
To some degree this is a limitation of how a Perl program gets parsed, but the more optional features and branches in the parser, the more difficult it is to maintain the parser. I know this sounds like a slippery slope argument, and a pernicious one. To some extent it is, but the parser and tokenizer and lexer are already a big ball of mud. Making that more so worries me.
With that said, the patch itself is as clean as you can reasonably expect. This is no criticism of Chip's skills.
The patch does too much
I like the idea of changing method calls from
$invocant->method to $invocant.method. I'd like to
experiment with that in my code for a while. (Back when I wrote P6 code,
that syntax was easy to use and easy to read.)
I'm ambivalent about changing the concatenation operator from dot to tilde. If there's a way to keep concatenation as it is, so much the better—but that probably means requiring significant whitespace around the concatenation operator and forbidding whitespace around the method invocation operator. The latter is troublesome; it would be a shame to borrow the problematic "unspace" concept from P6.
I'm not thrilled at all about using dot as a generic dereference operator,
turning $href->{key} into $href.{key}. That seems
to borrow trouble; think about bugs waiting to happen with that
code.
It might encourage fragmentation
While some parser changes merely add new keywords
(say, defined-or) or make code that was previously a syntax error
work (package BLOCK), this changes the meaning of two (maybe
three) operators which have worked this way for almost 20 years.
Yes, the effect of the dots pragma is local, as it should be, but
the effect also creates divergent dialects of Perl. Rather than having to learn
the meaning of new terms when the say feature is in
effect, dots means having to learn the new meaning of a term
when it is in effect.
That cognitive burden seems higher.
It's like updating the style guide on a well established project. Previously it recommended always quoting hash keys. Now it recommends the opposite. You'll spend time working with both styles until you scrub the old version out of your code and tests and support files and everywhere it's reached.
Yes, the lexical scoping of dots.pm helps, but do you really want
to sprinkle use dots; and no dots; throughout
existing code while you're making that transition?
If the use of dots.pm spread to the CPAN, could it ever be
contained? Modern::Perl was never supposed to be a dependency of
other CPAN modules, but it is.
It exposes but does not improve a problem of the Perl 5 implementation
This argument is subtle and fuzzy.
Patching the Perl 5 parser is relatively easy. (I've done it a few times.
When I added the ... operator, I had to work around a few issues
like this.)
Creating a local dialect of Perl should be possible. Every time you create a function (or import one), you're doing that. Every time you use a prototype, you're doing that.
Wouldn't it be nice if, Lisp-like, it were possible to create your own
dialect of Perl in which you can replace operators, add operators, or even
remove operators? (I won't miss reset, and I would love to fix the
unperlish contextual behavior of the x operator.)
Making that happen is a huge amount of work. It may never come to pass. Yet adding more branches and conditionals and special cases to the unholy union of the Perl lexer/parser/tokenizer seems to me to make that work even more difficult and even less likely.
I don't blame people for patching the parser to make these syntactic changes happen. It's much, much easier than fixing the parser to make these changes easier without patching the parser. Yet the latter is the right technical choice, even though it's more expensive now.
Yet that runs into the same problem as always. Perl needs to allow experimentation, but it shouldn't rush to ossify experments as core features merely because it's most expedient to perform these experiments in the core.
