What are some specific examples of backward incompatibilities in Perl versions?

Question

It has been 22 years between the initial public release of Perl 1.0 (December 18, 1987) and the current stable release 5.10.1 (2009).

During those 22 years the following notable releases have been made:

• Perl 1.0 (1987 - initial release)
• Perl 2 (1988 - better regular expressions)
• Perl 3 (1989 - support for binary data streams)
• Perl 4 (1991 - identifying the version of Perl described in the Camel Book)
• Perl 5 (1994 - major changes introduced, near complete rewrite of the interpreter)
• Perl 5.6 (2000 - 64 bit support, unicode strings, large file support)
• Perl 5.8 (2002 - improved unicode support, new IO implementation)
• Perl 5.10 (2007 - new switch statement, regular expression updates, smart match operator)

I'm looking for specific examples of backwards incompatibilities during the history of Perl.

Question:

• In the 22 year history of Perl, are there any examples of Perl backwards incompatibility where Perl source code targeting Perl version X won't run under version Y (where Y > X)?

Please include references and code examples when possible.

Answer 1

One of the biggest deliberate incompatibilities is array interpolation which changed between Perl 4 and Perl 5.

my @example = qw(1 2 3);
print "[email protected]";

In Perl 4 that would be:

[email protected]

In Perl 5 that would be:

foo1 2 3.com

Fortunately, if the array doesn't exist Perl will warn you about "possible unintended interpolation".

Threads underwent a big change between 5.005 and 5.6. "5005 threads" used the traditional POSIX threading model where all global data is shared. While in theory this was faster, because then Perl could just use POSIX threads, it was a nightmare for Perl coders. Most Perl modules were not thread-safe. And it never really worked well.

In 5.6, ActiveState and others made fork() on Windows. When you fork() on Windows, Perl would make a copy of the interpreter object and run the opcodes of both interpreters. This was known as "multiplicity".

In 5.8, Arthur Bergman ran with that and used it to create ithreads. Because multiplicity is emulating a separate process, no data is shared by default. Only data you say is shared is shared. This makes them much safer to use, though it took a long time before ithreads were stable. Folks like Elizabeth Mattijsen and Jerry Hedden made that happen.

5005threads were finally expunged in 5.10.0. A compatibility layer exists, but I doubt it would really work in production code.

Another big incompatibility came wrt Unicode between 5.6 and 5.8. Unicode in 5.6 blew. Whether or not a string was Unicode was decided by the surrounding scope. It was completely re-engineered in 5.8 so now the Unicodeiness of a string is tied to the string. Code written using 5.6's Unicode usually had to be rewritten in 5.8, often because to get 5.6's Unicode to work right you had to do ugly hacks.

Recently, 5.10.1 made a bunch of incompatible changes to smart-match. Fortunately they were introduced in 5.10.0 so its not a big deal. The story there is Perl 6 introduced the smart-match concept, and it was backported to a development version of Perl 5. Time passed, and Perl 6's idea of smart-matching changed. Nobody told the Perl 5 guys and it went out in 5.10.0 unchanged. Larry Wall noticed and did the equivalent of OMG YER DOIN IT WRONG!!! The new Perl 6 version was seen as significantly better and so 5.10.1 fixed it.

Answer 2

Pseudo-hashes are a recent example that spring to my mind. In general, perldelta files have an overview of incompatible changes in a specific version. These changes almost always either obscure (like pseudo-hashes) or small.