Why dots.pm Was Not My Favorite Feature

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.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 15, 2013 6:00 AM.

Continuations and the Web was the previous entry in this blog.

No One Needs Abstractions Until They Do is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?