Which edges cases could perl shed to make it easier to parse?

Bjørvika panoramic view

What would happen if we took the edges cases out of the Perl syntax? We were talking about this over lunch at the Nordic Perl Workshop. I wondered what would happen if we could make a grammar that other things that aren't perl could statically parse? This experiment doesn't care about backward compatibility. We end up with a slightly smaller

Part of the problem is that Perl code can run during the compilation and that can change the way that the parser works. What if that could still happen but the syntax would be the same?

The other huge problem is the availability of CPAN. Which features' disappearance would break CPAN beyond the point where people didn't want to use Perl? Not all of CPAN is important, and how hard would it be to fix these edge case syntax items?

  • attributes
  • prototypes (but improve signatures!)
  • all sub calls need parens (no perl poetry mode or different arities) (how does this affect $_ defaults.
  • single expression forms of map and grep
  • move some platform specific keywords to modules (kill was the focus of that part)
  • indirect object notation
  • require m on // for a match operator

I'm not quite at the point of seriously suggesting this as a project, but I think it's an interesting experiment to think about. What else could be remove to make parsing easy?

Some interesting reading:

10 Comments

The problem is you'll never remove all that stuff; too much prior art. The best you'll do implement another codepath without all that stuff, turned on with a pragma and now you'll have yet another codepath to maintain.

And isn't this what RPerl is trying do do, albeit approaching from the other direction, i.e.; removing stuff from an existing implementation as opposed to RPerl that's adding selected stuff to a new implementation?

Isn’t that more or less what Kurila was? Also, the Perl-alike Stevan wanted to attempt. And at least two other projects whose names escape me. I’m pretty sure there were more of them before my time as well.

History says that if you allow for breaking compatibility then you’re either Perl 6 or a dead project.

Why would that be? The way I see it, Perl has two value propositions: ① it’s a beautiful concise smallish language wrapped inside an ugly crufty big one; ② partly due to the former, there is lots of code written in the latter. If you’re going to break compatibility then it only makes sense to try to extract value proposition 1 cleanly, in which case it makes no sense to use the ugly crufty thing as a starting point. If value proposition 2 is what you’re after, then breaking compatibility is a death knell. If you try for “mostly like Perl but not compatible” you get neither value proposition and therefore no constituency.

It's about making a grammar that something else can use.

Oh. Hmm. PPI?

As I was a part of that conversation too, I'd just like to tag on that while some people are (rightly) interested in changing the grammar to improve parsers, I'm much more inclined to change it to improve the experience for newcomers. Things like removing indirect object notation, single quote package separator (`perl -E '$name = "Joel"; say "This is $name's computer"'` anyone?) and (IMO) the map EXPR, LIST form (because it is hard to teach/explain how that EXPR is deferred), etc.

Most of us monks don't use these because we know them for the footguns that they are, and even still lose a toe or two accidentally. Think how much better it could be for newcomers who don't know to avoid them.

Indirect object notation and Package'Separator should be gone. I would be sad for most of the other proposed changes.

What about the difference between


sort(find_records(@key));
sort(find_records (@key));

etc.?

I would love to see some of this worked on. However, to do that, we'd have to get P5P to agree to a policy on how to introduce backward-compatible changes. That seems like the biggest first obstacle.

I use map EXPR, LIST pretty often because it runs faster than map { BLOCK } LIST.

Leave a comment

About brian d foy

user-pic I'm the author of Mastering Perl, and the co-author of Learning Perl (6th Edition), Intermediate Perl, Programming Perl (4th Edition) and Effective Perl Programming (2nd Edition).