Correct or Compatible, Pick One

Try::Tiny shouldn't become a core module in Perl 5, because it works around a series of infelicities of implementation.

If Perl 5 were to address this problem, someone would have to rethink several well-established, fundamental design and implementation and language decisions. Someone would have to test them, not just with all of the core tests, but with all of the CPAN. Someone would have to document the changes and hope that the updated documentation would eventually make its way into new books on Perl 5 as well as all of the example code on the Internet. Someone would have to update existing code, especially on the CPAN, to take advantage of the new features.

This is all possible. It's happened before. Code people care about gets maintained, and if new features are useful in that code, people will update it to take advantage of new features. Similarly, features removed from a language or library get removed from programs when they update to new versions of that language or library. None of this is new and none of this is surprising.

The real problem in the case of exceptions and scope exit semantics in Perl 5 is that the initial design didn't anticipate the possible edge cases which make the feature (occasionally) unreliable. You can design all of the formal semantics of a language as much as you want. You can spend ten years writing a specification. You can prove the initial implementation with formal methods. Yet as soon as users start doing things you didn't expect, you'll run into cases the specification and design and intent don't cover, and then you have a difficult question.

If someone changed the way scope handling and exit and call stack unwinding worked in Perl 5, such that exceptions could never get lost and lexical destruction always occurred in a predictable order and return values propagated to the appropriate places, Try::Tiny would be unnecessary...

... and someone (probably that same someone) would have to provide a compatibility mechanism for all of the existing code which relies on specific details—documented and otherwise—of scope handling and leave semantics and destruction ordering as it exists in Perl 5.12 right now, to give people time to migrate to the new system and to notify them that the old system is deprecated and to find design and implementation infelicities in the new system.

If reading that paragraph wearies you, imagine how much more doing all of that would be.

Granted, fixing scope handling and destruction ordering and leave semantics is as big a task in Perl 5 (or any language) as anything else. It's doable, from the technical side. Yet how much sixteen year old code needs to change to achieve it, and how many assumptions in the billions of lines of code written in the past sixteen years need to change to make it work? Worse yet, this isn't a Moose situation, where an obvious improvement is available to anyone with a CPAN client and a few minutes to read a tutorial.

I don't mean to dishearten anyone. The edge cases for which Try::Tiny exists are rare, and you can write Perl 5 code for years without encountering them. It's an easy module to use and it shields you from most of the damage.

Even so, fixing bugs the right way—making them impossible to encounter—is not always easy. You don't often get a fresh start in software, but sometimes that's exactly what you need.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on April 14, 2010 1:39 PM.

Don't Core Your Workarounds was the previous entry in this blog.

Removing Friction is the next entry in this blog.

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


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?