In What if Perl Had a Specification, I suggested that part of the C language's staying power came from the fact that it allows multiple implementations of a regularly revised specification. That may be good for Perl—and I'll discuss that in a future post.
Very little in life is free, however. The downsides of a specification are numerous and real.
Who Writes the Specification
The biggest drawback of a specification process for Perl is that it'll require a lot of volunteer labor, if it ever happens. The last time this happened was The P6 RFC Process, and, over a decade later, you can see a few hints of the varied suggestions remaining after a small cohort of editors revised that specification into its current state.
Unlike a specification for an Internet standard such as a networking protocol, a mechanism to improve device accessibility in web pages, or even something as simple as allowing international characters in domain names, there's no industry lined up behind Perl with multiple multinational vendors and mutually cooperating and competing non-profit vendors already implementing parts of the specification and jockeying to have their ideas included with as few modifications as possible.
It's not even like the Java JSR process, where the Enterprisey software companies get together to design the worst possible persistence format, date and time library, or attempt to wedge dynamic programming into a static language through the use of convoluted frameworks driven by XML.
It's also not like Perl is a small language.
Standards are opinions, and if I were in charge, you'd see a language that looks the way I program it and not a lot of things that look like I don't.
What Gets in and What Stays Out
That brings up the second point. He or she who does the work does what he or she wishes.
If I were in charge, an ideal Perl specification would have strict and warnings and enforced version numbers in all files by default. That decision would instantly mean that almost all existing Perl files do not conform to the specification.
Someone else might remove tie and AUTOLOAD,
breaking big parts of the CPAN unwittingly.
There's probably little controversy over removing features such as
reset and srand and dump, but unbundling
a module such as CGI.pm affects real people and real programs.
Your small core might not be my small core. You might want CPAN.pm
as the bootstrap mechanism for the CPAN, while I might prefer
cpanm. You might want SysV IPC keywords available by default,
while I'm fine with them as a loadable module. You might want a guarantee that
the only symbols available by the core POSIX module are those that
Perl can provide across all platforms, and I might disagree.
If there's a solution, it's finding an extension mechanism. Even as much as the zeitgeist on p5p and PerlMonks and elsewhere might want to suggest that "Just install it from the CPAN!" is the ultimate solution, it's still not a ubiquitous solution.
Which Parts of the Implementation are Deliberate
Because Perl has never had a single specification created around a few axioms rigorously devised for maximum flexibility from a minimal combination of primitives, it's grown organically. That metaphor is deliberate. Nature is messy and nature is red in tooth and claw and nature resists attempts to make it conform.
In other words, Perl is good at things Perl was never deliberately designed to do and Perl is capable of things no one ever thought Perl would do, and one reason why is that Perl allows you to be messy. Perl has side effects and Perl has quirks of implementation.
Any specification will have to get into the details of how, for example,
polymorphic value caching works, or when you can treat a blessed reference as a
regular reference in the face of overloading or tie, or exactly
how cross platform things like symlinks and filesystem encoding or threading
implementations are.
A good specification ought to solve the question of reference counting of items on the Perl stack.
A great specification would draw a line around parts of the Perl XS API and codify what exactly is part of the API and what isn't and break large pieces of the CPAN until things get better. (If that disturbs you as much as it does me, good.)
Which Flaws Need Addressed
I write documentation last. If something's difficult or embarrassing to explain, I revise the code until it makes more sense. (Writing tests first helps with this, but doesn't always prevent it. Code and prose are different, and anyone who tells you otherwise should have a lollipop and step away from computers for a while.)
Even if all of the previous obstacles to creating a usable and useful specification are surmountable, arguments over whether a flaw exists and whether it's ethically acceptable to enshrine them in a specification (however ephemeral this version is) will arise. These will be nasty arguments. There's a strong reluctance to mark too many things as undefined corner cases, even when they exist.
(This is especially true in the Perl world, where it took ages to get rid of Perl 5.005 threads, pseudohashes, the Switch.pm module, smartmatch, XS, and indirect notation. QED.)
On the other hand, there will be pressure to fix bugs and corner cases before the specification comes out, but that's pressure on developer and tester resources, which means a prioritization process involving volunteers, and everyone knows how that goes.
Is it Worth It
This is a huge amount of effort.
Then again, other projects in the Perl world have used up huge amounts of resources, so that shouldn't mean the plan is unworkable.
It would be expensive and burdensome and take a lot of effort from a lot of unidentified people, as well as a lot of effort from people already burdened with the maintenance of the existing code and important CPAN modules. It'll cause arguments and fights, but some of those arguments deserve resolving anyway.
The biggest drawback is that Perl doesn't have a Larry; he's been doing the same thing for P6 for many years. Similarly, there's no Damian to provide the rigorous attention to detail bounded by practical experience teaching the language and helping users at all levels write workable code.
Is that a fatal flaw in the idea? By no means. The advantages to a specification are compelling—but it's important to be realistic about whether this might (or even could) ever happen.
