Which edges cases could perl shed to make it easier to parse?
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 (
killwas 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:
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).
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?
Prior art doesn't matter if you can break compatibility. And, it's not about doing this in the Perl source. It's about making a grammar that something else can use.
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.
Oh. Hmm. PPI?
Kurila wants to do new things. That's not what I'm proposing. I'm not interested in making a new language. Anyone can still use Perl just as it is.
I like the language I have now, but there are parts of it that I don't use that I think are probably causing a lot of pain to support and limits lateral development (like Perl on the JVM or something).
It's a false dichotomy though. I don't need to start from scratch. Perl is already doing this, for what it's worth, by removing features deprecated since 5.0, and that has some value.
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
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, LISTpretty often because it runs faster thanmap { BLOCK } LIST.