July 2000 Archives

Report on the Perl 6 Announcement

Last Monday, nobody knew that anything unusual was about to happen. On Tuesday, the Perl 6 project started. On Wednesday, Larry announced it at his "State of the Onion" address at the Perl conference.

Yes, it all really did happen that fast.

Several problems have seemed to beset Perl in the past year:

Infighting on p5p, the main Perl developers' list, seemed out of control for a while, and, although the problems seem to have been solved by the addition of refereeing (See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00574.html for details), several important developers had quit the list already.

But not a lot seems to have happened to Perl in the last year. The last really interesting Perl development was probably POE, which won the "Best New Module" award at last year's Perl conference. There was a Perl 5.6 release, but most of the changes were not user-visible. There was better support for threads (including support for fork() on Windows systems, which is very impressive) and Unicode. But it's hard to get excited about this, and it was really hard to put in, and incomplete.

Perl development was stuck.

Stuck How?

There are two big problems with Perl 5.

First, the internals are extremely convoluted. It's hard to hack on Perl's internals. There's a lot of accumulated cruft, and Perl 5 has reached that stage of maturity in which it's difficult to make a change or fix a bug without introducing some new bug. The excellent test suite prevents the new bugs from getting into the release, of course, but it also prevents the new feature from getting into the release.

The addition of threads, the compiler, bytecode generation, and Unicode support is still incomplete, because none of those things were designed into Perl 5; they are all being bolted on afterwards, and it shows.

The other big problem is thirteen years of backward compatibility history. The porters might like to rationalize the syntax a little, or clean up Perl's semantics, but that might break old code, and Perl is committed to not breaking old code. We can't add a new built-in function because it might break old code. It's extremely difficult to remove even the most bizarre and little-used old features, because it might break old code. Every few months, someone suggests replacing Perl's garbage collector with a more modern one, but there are always objections from people who have written code that assumes that the garbage collector will always be reference-count based and that it can control when objects will be destructed.

Technically, there's not very much "wiggle room" in the source code, because the internals are so convoluted and difficult. And there's not much "wiggle room" in the language itself, because of the need to support ten-year-old Perl 2 code.


I had to miss the Tuesday meetings, because I was teaching classes. So this part of the report is hearsay.

A meeting of the Perl 5 Porters was scheduled to take place in the afternoon. In the morning, Chip Salzenberg held a pre-meeting for discussion of "constitutional issues," to change the way Perl development was run. But after a while, according to Larry, "Jon Orwant ... pointed out that it was going to be useless to invent a new constitution if everyone was just going to say, 'Ho, hum.'" Jon suggested that Perl try to go in a new direction, and do something new and big; he used Napster as an example of a new, big idea. This was the catalyst for the discussion to go in a new direction. At the end of the the morning, the decision was made to start working on Perl 6.

What About Perl 6?

Perl 6 will be a complete rewrite of Perl, starting from scratch. The internals will be redesigned. Threading, Unicode, and reliable signal handling will be designed in from the bottom up. The external API will be cleaned up; the core will be smaller and faster, and the XS system for extension modules will be scrapped in favor of something simpler and cleaner. One perennial problem has been that installing a new version of Perl has frequently broken binary compatibility with older versions and required that all of Perl's unbundled extension modules be recompiled; this may be fixed in Perl 6.

At the same time, the social structure behind Perl will also be redesigned. Larry said that the perl5-porters model was not working well any more, and led to too much talk and too little action. Perl is too big for one person to manage, and the pumpkings burn out quickly. The new model will probably be several separate working groups, each charged with the design and implementation of one aspect of Perl. Larry said that Perl 6 would be designed by the community, and not by one person, and that with the new organization, Perl would be able to evolve into the language that we need in 2020.

Probably most amazing was that the Porters agreed to break backwards compatibility. As Larry said on Wednesday, the language itself needs revision. On Wednesday, Larry mentioned several small, specific changes:

  • The system() function will return true on success and false on failure.

  • The localtime() function will return the four-digit year.

  • The notion of "currently selected filehandle" will probably go away.

  • Typeglobs may be eliminated.

But these are just by way of example. Larry said "We're really serious about reinventing everything that needs reinventing." Everything is up for discussion, and the suggestions so far have even included giving Perl a pattern-matching system more like the one in SNOBOL.

It seems that the big technical inspiration that came out of the Tuesday afternoon meeting was that it doesn't have to be backward compatible. Perl 5, right now, can compile a Perl program into its internal syntax tree and then uncompile the tree back into source code, using the B::Deparse module. But you don't necessarily have to produce the same source code you took in; you could instead rearrange the code to produce a Perl 6 program to do the same thing. So the upward migration path from Perl 5 to Perl 6 will probably be to run your code through a translator.

Larry promised not to abandon Perl 5. The 5.6 maintenance track will continue as planned, and the 5.7 development track will eventually yield Perl 5.8, as planned. 5.8 will be the final release of Perl 5, but it will continue to be maintained and stable. Larry pointed out that Perl 4 had not yet gone away, and there was no reason to expect Perl 5 to go away either. CPAN itself can serve as a test suite for Perl 6: When it can run most of the things in CPAN, either directly or post-translation, it's ready.

Larry said that easy things should stay easy, hard things should get easier, and impossible things should get hard. He promised code in one year: alpha code, but well-designed alpha code, and he called on each person to play their part.


At the end of Larry's announcement, Jon Orwant graciously offered to cancel his talk on "Rebuilding Postapocalyptic Civilization with Perl" so that Larry could have a question and answer session. These are the questions that people asked, with Larry's answers.

Will Perl 6 be in C++?


When can we expect the grand plan?

Larry said that culturally, it has started already, and that we should expect a roadmap this month. His personal goal as language designer was to have something substantial to say by the time of his Linux Expo keynote speech in October. But the schedule is not yet nailed down.

Will Perl 6 have a spec?

Larry said he did not know how strict it would be, and that he was not big on specs. He likes the reference implementation approach. He said he wanted to particularly stress not a spec, but the development of acceptance tests into regression and validation tests that would say "This is Perl; this isn't." He said that this was more important than mere verbiage.

Will you look into technical infrastructure to support more constructive discussion than mailing lists can?

Larry said that the Porters were thinking about 2-tier mailing lists that each have a person in charge, and an RFC-like mechanism. He said that we would be paying less attention to the "Wouldn't it be nice if..." type of proposals, and that proposals would need to be more formal and official.

Can you hint at some of the language changes?

Larry said that everything was negotiable. He specifically mentioned that Perl's old "formats" feature should probably be in a module instead of in the core, and that he wanted to clean up ambiguities in the indirect object syntax. (This question concerns whether the notation

        my $x = new Carrot (...);

parses as if you had written

        my $x = new(Carrot(...));

or as if you had written

        my $x = 'Carrot'->new(...);
instead. At present, this construction is rather fragile.)

Larry said that since the Porters had decided to bite the bullet of backward incompatibility anyway and require translation of Perl 5 to Perl 6 code, they would consider any change at all, as long as it could be translated. He said that if 95% of all scripts could be translated 95% accurately, and if 80% of scripts could be translated 100% accurately, that was probably good enough.

He said that the Porters wanted Perl to have all the features that other languages say "nyah nyah" about, such as byte-compilation. He suggested that Perl's garbage collector might be replaced with a more modern mark-sweep garbage collector, and that object finalization might be separated from destruction.

One problem of language translation is that you lose comments and formatting.

Larry replied that a2p, the AWK-to-Perl translator that is bundled with Perl, which he wrote, doesn't have this problem, and that he didn't think that the person asking the question would need to worry about this.

Is there a possibility of getting a switch construction?

(At this point Damian Conway shouted "I have a paper on that!")

Larry said, "Certainly." (Meaning that there certainly was a possibility, not that there certainly would be one.) Then he said that he would not promise one.

Will there be an ISO or ANSI standard for Perl?

"We will be our own standards body."

How long have you been thinking about this?

"Since yesterday."

What about POD?

Larry said it was all negotiable.

Which languages will you borrow from this time?

"All of them."

(Then Larry said that they probably wouldn't borrow COBOL's IDENTIFICATION DIVISION syntax, and that part of the reason there was so little COBOL poetry is because it's hard to write a poem that begins IDENTIFICATION DIVISION.)

He also mentioned the bytecode issue again, and said that it would be nice to have a cleaner object-oriented interface to I/O.

Some people using Perl to develop large software want features like strong type checking. Is there a possibility of providing this?

Larry said there was, and suggested a use strict 'typechecking' directive, or maybe use stricter. He also said that perl 6 should get rid of many of the stranger global variables, such as $#.

Other Resources

The official web site for Perl 6 right now is http://www.perl.org/perl6/. The site has a list of short-term goals, a list of the roles that have been assigned to various people, the notes from the Tuesday afternoon meeting, and press releases concerning Perl 5 maintenance and Perl 6 development.

Editorial Conclusion

Perl is interesting again.

Choosing a Perl Book

There are a huge number of books out there about Perl. A quick search onAmazon reveals 362 books; allowing for false positives and books where Perl is a minor part, I'd conservatively estimate there to be over 250 books primarily on Perl on the market at the moment. Are they any good?

Of course, if you don't know any Perl, it's impossible to say. There are a few good reviews out there -- Tom Christiansen maintains a review site, and the Perl Mongers have a set of reviews of some of the more popular books too. And you can listen to personal testimonies from people who've learnt from the books -- but they'll only tell you about the quality of the teaching, not about the quality of the Perl. If you want to make sure you're learning high-class Perl, you need something external and objective.

So, let's have a look at a few criteria that you can use to evaluate Perl books yourself; this is basically how I'd go about stress-testing a new book when I got hold of it. If you don't know any Perl at all, you may want to ask a friend to check a book out with you -- some of these tests ask you to look for certain concepts and examples, and if you don't know Perl, you won't necessarily know how to look for them!

First, though, it would be deceitful of me not to open with a declaration of bias: I have written a beginner's book on Perl, and obviously, I think it passes most of the tests I'm about to cover. However, I'm not going to advertise here. The beauty of the free software world is that you have freedom of choice, and that includes the freedom to choose how you learn. My book may not suit you, but someone else's might. That's fine. All I want is to make it easier for you learn Perl, and this list should help you find a good way to do that. Nevertheless, you might want to take what I say with a pinch of salt, pepper, and Dijon mustard.

Anyway, on with the tests!

Who's the author?

The first test is by no means an acid test. It's a hint, and that's all. But good Perl programmers and teachers tend to be known in the Perl community. It's perfectly possible for a Perl expert and an excellent author to appear out of nowhere. But it's rare.

Perl encourages co-operation. We've got a huge repository of code, the Comprehensive Perl Archive Network, which enables people to share their code with the world. If someone's a really good Perl programmer, it's highly likely they'll have come across a problem, abstracted the solution into a module, and uploaded it for the benefit of others. So, check out CPAN; you can search for the author's CPAN directory at http://search.cpan.org and see what they've submitted, if anything. If they've got a directory on CPAN, then you can download their code and have a look at it. Is it documented? Is the documentation clear and easy to read? Does the code pass the other tests here?

Another way people make a name for themselves in the Perl world is to get involved with the development of Perl itself, in which case they'll be posting to the perl5-porters mailing. Have a look at their posts, and see what sort of attitude they take about Perl.

Thankfully, not everyone's a core developer, and -- don't get me wrong -- not being a developer is by no means an indication of not knowing Perl. However, if they do appear on perl5-porters posting intelligent stuff, this should be points in their favour.

Similarly, do they have a presence on Usenet, mailing lists, or Perl IRC channels? Larry says that "Perl folks are, frankly, some of the most helpful folks on earth" -- so is your potential author spending time helping people out?

Again, this isn't an acid test -- some people can't stand Usenet or IRC, some people (myself included) get far more mail than they can respond to, and some have restricted Internet access, which makes it difficult for them to get involved in this sort of thing.

But if you find someone helping out and getting involved in mailing lists and Usenet, you've got a good opportunity to look at their style, to see how they answer questions, and to see how they deal with issues that might seem obvious to them.

The more information you can find about the author, the better.

Ways To Get Help

Perl comes with a huge set of documentation: at last count, 70,000 lines of reference, tutorials, and other information. No introductory Perl book could ever cover all that, nor should it. As Samuel Johnson said, "Knowledge is of two kinds: we know a subject ourselves, or we know where we can find information about it." Since a Perl book isn't going to cover everything about the language by itself, it's important to impart the second kind of knowledge as well as the first.

So, what does a good book need to tell you? It needs to talk about the various documentation pages available. It needs to explain the perldoc program for finding and reading the documentation. It needs to mention the perldoc -f interface to the functions documentation perlfunc, and, for books published in the past couple of years, the perldoc -q interface to the Frequently Asked Questions list. Ideally, it should give examples of how to solve problems by referring to the FAQ and the functions documentation; stress on how the user can find information by themselves is important.

Finally, it needs to talk prominently about the fact that all Perl modules contain their own documentation, itself available via perldoc, and that programmers should write their own documentation in the same way, using Perl's Plain Old Documentation.

use strict and warnings

One objective a book should have is to encourage good programming style, and Perl has many ways of helping programmers develop such a style.

The most powerful is the warnings system. Perl's warnings catch a lot of programming errors, and point out bad programming practices. There's absolutely no excuse for having a program that doesn't run cleanly with warnings turned on, especially if you're setting an example for others to follow.

In Perl 5.6.0 and later, the warnings system is controlled by the words use warnings; in previous versions of Perl, -w should appear on the first line of a program, usually after something resembling #!/usr/bin/perl. If the author isn't encouraging you to use warnings -- if you don't see a -w on the top line of examples of full programs, or a use warnings somewhere near the top of the code -- put the book down. Forcefully.

The second method is a little more contentious, and I'll be discussing why next time. Perl has a way to check that you know what you're doing with your code: it forces you to be clearer with your use of variables and subroutines, and it stops you from using symbolic references (which we'll come to in a moment). Essentially, it's an idiot trap. It tells Perl to be a lot more strict about what code it'll run, and so it's called strict.

When you're programming casually just to get a job done by yesterday, you don't need that kind of strictness. It's OK not to use it if you fully understand why you should use it. On the other hand, if you're teaching people, you want to be presenting them with the cleanest code possible, and you want to encourage them not to be sloppy with their programming. So, look for the words use strict around the beginning of the examples. Some elements of strict are concerned with variable use and scoping, which may not be discussed until quite late in the book depending on how the author's chosen to lay it out, so don't worry if you don't see use strict in the first few chapters. If you're still seeing examples at the end of the book that don't contain it, be suspicious.

Return values on system calls

Another good programming practice to encourage is defensive programming.

Defensive programming is the idea that if things go wrong, you find out early rather than suffer embarrassment later on. There are already far too many programs out there that attempt to open a file, and then blindly write away assuming the file was opened successfully without actually confirming this. All your precious data is pumped into a black hole. If warnings aren't turned on, you won't even know about it. This isn't good. We don't want this. Even if you think that ninety-nine times out of a hundred your open will succeed, that's one bad time too many.

So, when we do anything involving the operating system, we make sure it worked. Most calls to the system handily return a success-or-failure value, so we can test them easily. You should see examples using forms like this:

    open FILE, $filename or die "Couldn't open filename: $!\n";

That's pretty much the canonical form, with the possible use of || and bracketing around the parameters to open instead of the or, like this:

    open(FILE, $filename) || die "Couldn't open filename: $!\n";

If the author uses something other than this, you might consider accusing them of avoiding idiom, something else we'll look at soon.

However, the point is that some sort of checking should occur. This is great:

    if (!open FILE, $filename) {
        print "Something really bad happened. Sorry.\n";

But this is dangerous:

    open FILE, $filename;

Examine the examples, and judge accordingly.

Symbolic references

Yet another instance of good programming practice is the avoidance of symbolic references, and a treatment of the variable-name-as-variable question.

The question usually runs something like this: We read in a value from the user -- say, "fruit" -- and we put it in a variable, $wanted. What we want to do is to get the value of the variable $fruit, using the contents of $wanted as our variable name.

Perl can do this, of course. But this is something you probably don't want to do, and it smacks of a need to rethink your design. A book might tell you how -- you say ${$wanted}. Of course, this won't work if the author's making good use of use strict, but we live in an imperfect world.

The problem with these symbolic references is that they allow you to get -- and change -- the value of any variable in the program. Given that Perl keeps important settings about how it runs in special variables with names that could quite easily crop up if things go wrong (_, *, ., and so on), this is quite a dangerous practice. It's especially dangerous since Perl provides a nice, easy way around this: a hash can store and retrieve this data without affecting any other part of the program.

A Perl book needs to mention this, since it's an idea that a lot of novice programmers have, and the solution needs to be the right one.

Treatment of localtime

This is less of an issue now that we're post-Y2K, but for books printed before January 2000, have a look at how they treat Perl's built-in localtime operator. They should mention that the operator returns a human-readable string when used in scalar context, but that's pretty basic. The interesting question is how they deal with the sixth element (or fifth, for those of you counting from zero) of the list it returns.

This isn't the year. It looks a bit like the year, but it isn't. They might describe it as the year, but it isn't. See, last year, it returned 99. A lot of people saw the 99 and assumed that (localtime)[5] returns the last two digits of the century. This caused a lot of hilarity in January when (localtime)[5] started returning 100, and a bunch of bad code got very confused.

The thing is, it wasn't 99 AD last year, just like it isn't 100 AD this year. It was, however, 99 years after 1900, just like it's 100 years after 1900 this year. That's what (localtime)[5] is -- the year minus 1900. (Hey, don't blame us. We inherited it from C.)

Any book that describes (localtime)[5] as being the last two digits of the year had better be making some adjustments pretty soon....

Explanation of Context

Perl's functions and operators do things differently depending on whether the thing that's calling them is expecting to receive a list, a single value, or nothing at all; this is called B<context>. It's an area that's not very intuitive to existing programmers, and needs to be covered well. Find the section on context in the book you're evaluating -- there is one, isn't there? -- and read it through twice. Do you understand what's going on yet?

Explanation of Lexical versus Global

A consequence of using the strict method of keeping your code clean is that you have to distinguish between lexical and global variables.

Perl has two different systems of variables; Mark-Jason Dominus explains the difference perfectly in his Coping With Scoping tutorial. Does your book cover the difference as well as that?

Treatment of Bitwise Operators

This is more an indicator of the author's attitude than a solid test of competence.

Perl provides bitwise operators to manipulate numbers and strings on a binary level. The thing is, you've hardly any cause to use them in ordinary Perl programming. Perl's more of a high-level language than that, and there's rarely a need to get into bit-twiddling.

If a book has a section on the bitwise operators, |, &, ~ and ^, consider why. Are they actually used again in the course of the book, or are they just for show? As mentioned earlier, books for beginners don't need to -- and possibly shouldn't -- tell you everything about the language. Only what you need.

Proper use of vocabulary

For those of you who already know Perl, ask yourself whether the author is using vocabulary in ways you expect. Some authors believe they can explain concepts better by creating their own names for them. But there's really no need for an author to make up their own vocabulary for elements of the Perl language -- we've already got a perfectly good set of vocabulary, and inventing more words only leads to confusion when the learner is trying to communicate with another programmer.

Operator Precedence

Does the author explain how Perl's operator precedence works? Is time taken out to discuss traps like this one:

    print (2*3) + 3;

This will print 6, not 9, because Perl sees print(2*3) and then adds three to it. This is something that far too many programmers fall into, and something that far too few books explain. Once it's explained and the reader understands how it works, it makes perfect sense. Otherwise, you'd have never thought of it. So the author has a burden and a duty to explain traps like operator precedence; at the very least, the book should contain a table of precedence, which should mirror and explain the table found at the beginning of perlop.

Treatment of hashes

A good Perl book explains not just what a hash is, but why and when to use one. Briefly, a hash is a collection of correspondences: a phone book is a hash that corresponds names with phone numbers. But that's not all hashes are for.

I mentioned that hashes can be used as a much neater solution than symbolic variables; hashes should also be applied to finding unique elements and counting the number of each different element in a list. Any time the word "unique" appears in a question, it should set off hash-sounding alarm bells.

Use of Modules

A great many problems I see newcomers struggle with are problems that have been solved before and made into modules. Perl philosophy encourages the reuse of sections of code and the sharing of solutions; we don't want anyone to repeat the mistakes we had to make. Tasks like reading through HTML or understanding CGI requests are actually far more difficult than they might first appear to the novice programmer, and it's almost always better to use code that's known to be good.

So, Perl has a great library of tried and tested code, the CPAN we mentioned earlier. The book should explain how to use modules, which modules are good for common tasks, and how to locate, download, and install modules from CPAN.

Furthermore, the book should positively encourage the reader to check for existing modules before attacking a problem; it's not just a practical matter, but also a matter of Perl philosophy -- Perl people don't like reinventing the wheel, and they don't want you to reinvent it either.

Treatment of CGI

A special case of this is the CGI module or its derivatives. CGI is a particularly knotty area, although it seems relatively simple at first.

Any book dealing with CGI -- and that's going to be most books about Perl these days -- needs to get a few things straight.

CGI is a protocol. It's not a programming language. It's just a formal agreement between a web server and a program -- maybe in Perl, maybe in another language -- that they're going to do things in a certain way. That's all.

The problem is, CGI is quite a complex protocol; it has two methods of getting data to a program, each of which works in a different way. Your program can't ensure in advance which way it's going to get the data. The data is encoded in a specific way; there might be a file attached, and the data will have to be encoded slightly differently again. It's a tricky problem, and this is exactly the time that programmers need to be relying on tried-and-tested solutions. Emphasis on the CGI module or CGI::Lite is absolutely and utterly essential.

Taint checking and security

Similarly essential is a discussion of secure programming; a quick browse over Bugtraq or any other securities advisory mailing list turns up a bunch of CGI programs written in Perl that have gaping holes. For the most part, these problems could have been easily avoided.

Perl provides a mechanism, taint mode, for helping programmers think about the security of their programs. It doesn't write secure programs for you, but it forces you to think about what you're doing with your data. It does this by flatly refusing to perform certain operations on data derived from the outside world -- such data is "tainted" and needs to be cleaned up before it is used. Taint mode is turned on with the -T flag to Perl, and so "serious" examples of CGI programs really really ought to start something like this:

     #!/usr/bin/perl -wT
     use strict;
     use CGI;

for books published before 5.6 was released, and

     #!/usr/bin/perl -T
     use warnings;
     use strict;
     use CGI;

for those published after. If not, put down the book and hunt down the author.

The other thing to note is that turning on taint checking doesn't mean your program is immediately secure -- a good Perl book should examine other things that can go wrong, such as race conditions, temporary files, file permissions, symbolic link chasing and so on. Bonus points for those that talk about the Safe|Safe module or other modules that "sandbox" Perl's operation.

Perl Philosophy and Idioms

The final category we're going to examine is the most nebulous and vague, and also the most difficult to spot. You want to examine whether or not the author understands and follows Perl programming philosophy.

The most important part of this is that the author should not shy away from using idioms. Perl's a living language, and you can never get a complete understanding of a language unless you speak the way the natives do -- "classroom Perl" stands out just as much as "classroom French." Besides, out there in the real world, you're going to be coming across idioms in other people's code, and a good book should prepare you for these.

So, does the book stick rigidly to structures like this:

     if ($this) {

or does it make use of more relaxed forms:

     $this and that;
     that if $this;

Does the book use unless, or stick to if (!...)? If it mentions select, does it explain select((select(OUTPUT_HANDLE), $| = 1)[0]);? Or how about ($a, $b) = ($b, $a)? What about switch statement idioms? Similarly, Perl has some nasty traps even for the best programmer. (Some of these are detailed in perltrap.) Are they mentioned and explained in the book?

The overriding point is that the author should be prepared to get your hands dirty. People out there speak slang, and you're going to need to understand it.

Final Thoughts

Here are a few less important thoughts and questions I've come up with to finish off your evaluation. Some of these are a matter of taste, so I'll leave you to pick and choose.

  • The language is Perl, the interpreter is perl. Neither of these is PERL.
  • Any book published after 1996 with "Perl 5" in the title is missing something. It's been Perl 5 since then, and I don't think anyone is teaching Perl 4 these days. It's just Perl.
  • You can't learn Perl in 24 hours, 21 days, 12 weeks, 9 months, or a year. I've been programming Perl for nearly five years and I'm still learning.
  • Do the examples follow the style conventions in perlstyle?
  • Tom Christiansen has some notes about the typography of a book, particularly on the use of monospaced typefaces for code and screen output, distinguishable quotes (can you see the string '"`'?) and brackets (what does [({E<gt>E<lt>})] look like?), and sensible layout.
    1. Is there a section on, and explanation of, one-liners? They're quite a part of Perl culture.
    2. Larry said "Perl programming is an *empirical* science." Are readers encouraged to try things out when they're not sure how something works?
    3. Learning Perl is meant to be fun. Is it fun to read, or is it dry and clinical?

Hopefully, I've given you some useful criteria to use in evaluating some of the many books out there. Use these in conjunction with Tom's reviews, Michael Schwern's reviews, Uri Guttman's Perl Books Page, and the Perl Mongers book reviews, and you'll be able to get an all-round view of the "Perlishness" of a book.

I sincerely hope you find a book that makes Perl easy and fun for you, and that gets you into good habits immediately.


Credit is due to Michael Schwern for the Five-Minute Perl Book Review. This article is derived from a post on the perl-friends mailing list, and Chip Salzenberg and Abigail added their thoughts there. Nat Torkington reviewed this article and gave several helpful comments. Hopefully he will be writing a "Reviewing Perl Books" article soon.

Reports from YAPC 19100

Reports from:

Schuyler D. Erle
Gene Boggs: Day 2
Sean M. Burke
Uri Guttman
Brad Murray
Lisa Nyman: Report from a First-time Presenter
Clinton Pierce
Nathan Torkington
Adam Turoff
Mark-Jason Dominus

Last month Yet Another Perl Conference 19100 was held at Carnegie-Mellon University in Pittsburgh, Pennsylvania. I promised a conference report when I got back, but once again found that I couldn't really write it myself, because I had been a speaker and so had missed a lot of the things that went on outside of my own events.

While trying to decide whom to get to write the report instead, I realized that I was tired of conference reports written by one person. Instead, I followed the pattern of one of the conference's big successes, the Lightning Talks, and asked about twenty people to each contribute a very short report on one or two aspects of the conference.

The reports follow. For more information about YAPC, visit http://www.yapc.org/. Also note that the first YAPC::Europe conference is coming up in London in September.

Schuyler D. Erle

The first big highlight was probably Larry Wall's opening speech on Bunyan's The Pilgrim's Progress and the development of perl, but I found the talk's concluding Q&A portion really unforgettable. Someone asked Larry what the first thing was that he would go back and change about perl, given the chance. His answer was succinct: The return value of system(). `"Obviously," he announced, "If you want to succeed, be true."

Friday's big excitement was mjd's Lightning Talks, a sort of Conference Proceedings for the Attention Span Impaired. A lot of people turned out to see the five-minute talks, most of which were really well delivered. Amazingly, all of the speakers kept to their allotted time, as marked by Dominus with a gong he seemed to have mysteriously acquired for that purpose. The highlights of the Talks were universally accorded to be Nat Torkington's twin discourses on "A Day in the Life of p5p" and "What is it with those Python fucks, anyway?", the latter of which was thoroughly tongue-in-cheek, absolutely hilarious, and it's too damn bad for you if you missed it because Nat has, apparently in the interests of peace, refused to make the text of the speech public. "Of course our wheel is square. It's easier to measure that way."

But, as always, the best part about YAPC is the people. After Friday's proceedings, I, with every intention of going down to Forbes Av. and getting too drunk to walk back to the dorms, instead happened upon what apparently started out as an idle chat with Larry and Sean Burke and mjd and a few others, and became this mad informal panel discussion in the lounge that started with the genus of shellfish the Phoenician used for dye and somehow ended up moving from there to the philology of Lisp and Cobol to the decipherment of the Codex Seraphinianus and beyond, digressing continually for all kinds of other esoteric insanity. I mostly sat and listened, utterly fascinated. I never did make it out to the bars. I swear, the perl community is a bright lot, and, boy, YAPC is a great place to get a healthy dose of humility. Thank God it only happens once a year.

[ Details about the Lightning Talks are available at http://www.plover.com/~mjd/perl/lightning-talks.html --D. ]


For me, YAPC started around 9:00 on Wednesday, June 22nd. I showed up a bit too late to catch Kevin Lenzo's introductory talk, but just in time to catch Mark-Jason Dominus' talk on strong typing, an interesting talk about the pitfalls and triumphs of typing systems in various programming languages. Mr. Dominus is an incredible speaker, and even while he was clearly quite exhausted, the talk was very interesting.

After this talk, I hopped over the Randal Schwartz's "Learning Perl" room for about an hour. Now I can't say how good this talk is for perl beginners, not having been one myself for quite a while, but I always like to go see Randal speak for at least a little while at these conferences. Every time I go, I learn something new about perl that I just hadn't noticed before. For example, at YAPC I learned about the return value of print and the behaviour of reverse(@). However, I can only last about an hour before the dreadful jokes and auctioneer-style patter start to really get to me.

After lunch I returned to the Dominus room where the famed "Wizards" talk was getting under way. In just under an hour and a half, I learned an immense amount about globs, knobs, references and other sundries that go on under the cover of the stash. Unfortunately, shortly after the final break for the day had begun, I was again overcome by anxiety and had to leave. I spent the rest of YAPC at home and at work, but I hear it was also very cool.

Gene Boggs: Day 2

Woke up and made for the shower to catch Larry Wall's opening talk, stopping only to smile as Larry and backpack walked silently by.

Got to the auditorium (after wolfing down excellent catered YAPC breakfast of fresh fruit and bagels), sat by mjd, and listened to Larry speak through the allegorical adventures of Christian in the book, "Pilgrims Progress."

Sean M. Burke

Listening to a Damian Conway talk (whether about OOP, or about quantum programming) is like going to an old-time Grateful Dead show: it goes on hours longer than expected, but by even halfway through you're tripping too hard to care.

John Orwant's talk discussed concepts of copyright by pointing out design features of things (an ashtray, an ice bucket, a lamp!) that he snuck out of his hotel room -- using stolen property to explain intellectual property.

As to the post-talk festivities: There's not many conferences you can go to where people, once a bit drunk, will declare how delicious the word "ontogenesis" is, swap tips on where to get a copy of the Codex Seraphinianus, and then go make fun of whatever's on ESPN.

Uri Guttman

  • highlight: quiet dinner with 2 friends on saturday night after it was all over in a very nice place overlooking pittsburgh.
  • lowlight: seeing bill in a hooters top.
  • in between light: picture of me and hooter girl
  • fun moment: wading in hotel lobby fountain at 3am.
  • best talk no one understood: damian's quantum superposition.
  • best bof no one came to: dual giant screens of the marx brothers' horsefeathers.
  • nicest ending: lightning talks that were cut off before you got bored or too much information.
  • best new friend: jasmine.
  • best previous friend: damian.
  • most rigged raffle: perl mongers (dha won the cpu).
  • #perl moments: getting to know faces and voices to attach to all those nicks.
  • most violent talk: damian's advanced klingon objects
  • cool thing: logging in to home box via ssh and reading mail in emacs.
  • best drink: mad mex fresh raspberry margarita

Brad Murray

YAPC was an interesting mix of brilliant, delightful, vulgar, pompous, engaging, boring, and fun people. I say people, because the people eclipsed the event proper. When I think about what talks I went to see and why, I realize that I went to see a certain person speak and not to see a certain topic elaborated. So what we had was essentially a huge multi-day all-night technical bull-session with a wide variety of people, led by the cream of the crop. Well, frankly, what could be more fun for a crowd of geeks?

Yes, fun. Sure, I justified all my expenses as training costs to my employer, but at the end of the day we had a lot of fun. Certainly some great things were learned, but mostly contact was made with plenty of smart people and we had a good time doing it. What I remember most vividly, for example, are events that happened far from the conference schedule:

Discussing the autism and language with Larry Wall, Sean Burke, and Mark-Jason Dominus at some terrible hour in the crossroads of the dormitory.

Having my room invaded by several luminaries for an impromptu discussion on Perl, the universe, and Space Ghost at 3am while trying to prepare slides for my talk the next day.

Being discretely offered computing services in the wee hours by folks who should know better but feel that getting Larry on-line at 4am is more important than the rules.

Being offered long distance cell phone time from a large number of caring #perl folks so that I could call home and talk to the sweetheart we had to leave behind for the week.

Throwing a frisbee on the lawn with Perl people when it was so dark that the disk could not be seen until it was 2 meters from your face.

I'd chew off my own leg before missing the next one.

Lisa Nyman: Report from a First-time Presenter

While I have presented papers at other conferences in the past, I have always been nervous about presenting at a Perl conference. I thought no one would find my work interesting or innovative. I was wrong.

YAPC was the ideal venue to discuss my latest project (the Census 2000 Internet Form) and all the open source issues related to its development. Being a speaker opened up a lot of conversations with people who, in their search for advocacy support, were curious about my agency's work with Perl and open source. Someone asked me optimistically "But is open source part of your agency's strategic plan?" Well, it isn't, but that hasn't stopped us from depending on it.

So gather your ideas and start putting together your presentations for next year. Use your local PerlMongers meetings as a proving ground. Take advantage of the small crowds and congenial atmosphere of YAPC to get your feet wet in the waters of the Perl conference circuit.

Clinton Pierce

Initially, I had two goals for YAPC. The first was to get in touch with some of the Perl Culture that I've been missing out on. Second was to learn some things about Perl that I really didn't know.

I attended Dick Hardt's "Programming for the People," and the talk itself wasn't the part I found fascinating -- it was the audience. The surprising thing was how heavily they (and Activestate!) rely on the Perl Culture as a backbone. They want someone like Activestate to give them polished tools. They need the gurus and "heavies" of the Perl culture, if for nothing else to tell them where to go. For them, it's not important that Perl is a swiss army chainsaw -- they're interested in the service department, sales staff, and the user groups. They can't get this level of support from any other toolset. And I agree completely.

A lot of the new Perl I learned wasn't perl. First was MJD's talk on why a strongly typed Perl doesn't have to suck. A lot of the talk was about ML! It may seem out of place, but learning just enough ML to really see the benefits of strong typing kind of makes me hope that Perl 6 has some of that as an option. (I feel so dirty!) The JAPH talk that I went to wasn't really Perl either. It was terribly perverse laughing at how Perl can be molded to even the most twisted of minds (Hi Abigail!). If you've never been able to decode a JAPH before, find Abigail's slides on the Web and learn frightening things about the language you THOUGHT you knew.

[Abigail's JAPH talk slides are available at http://ucan.foad.org/~abigail/Perl/Talks/Japhs/ --D.]

Nathan Torkington

Getting to YAPC was miserable. United screwed me over a ticket change, so I had to pay $700 at the last minute for tickets on Vanguard. They ran late, I missed my bus on the return trip, and so on. Bah.

I had a great time at the conference proper, oh yes. I got to see all my friends, catch some great talks, and have some fun giving talks.

Friends. Standout evening: getting toasted at the church brewpub (http://www.churchbrew.com/) on Saturday night. Other highlights: discussing the philosophy of OO and teaching OO with Damian Conway and Joseph Hall; sitting around the hotel bar in the evenings with Jarkko Hietaniemi, Elaine Ashton, Sean Burke, Jon Orwant, and Mik Firestone, yammering about everything until the wee hours; Mik's killer hooch (home-aged lemon and vodka); Elaine's whiskey; the trip to Falling Water on Saturday with Jon and Damian.

Other people's talks. Damian's Quantum Superpositions talk was stellar, even if it did lead to tedious repetition of the phrase "in constant time" afterward. Jon's Apocalypse talk was a fine continuation from last year's. Adam Turoff's Quizzo was a lot of fun (I'm not just saying that because our fabulous team placed) and I hope we see it again next year. The lightning talks were cosmic and I liked them so much I'm going to beg Mark-Jason to do them next year at TPC.

My talks. My three hour tutorial on "The Seven Stages of a Perl Programmer," based on a great post Tom Christiansen made to perl5-porters in 1997 was fun. I gave two 20-minute talks on advocacy and the uniqueness of Perl, while my head spun from cold medicine. And I gave two five-minute lightning talks, one satirizing the perl5-porters mailing list, and the other a Dennis Miller-style rant against the over-zealous Python advocacy I've seen lately. Notes for all my talks, except the Python rant, are at http://prometheus.frii.com/~gnat/yapc/.

Summary: a blast. Can't wait to do it again. Great job, Kevin!

Adam Turoff

While at YAPC this year, I would look around every so often and wonder if the conference program was an elaborate ruse to get nearly 400 Perl programmers together to sit and chat.

One discussion I had on the way to dinner was about what's broken with CPAN. One of the points mentioned was that Perl in general and CPAN in particular does not accept multiple competing implementations of modules. On the one hand, it sounds like a violation of TMTOWTDI, but on the other hand, CPAN symbolizes The Perl Way. Playing with this idea in detail, I began to realize that there's a zeroth law that supercedes TMTOWTDI: Perl encourages sharing and collaboration over standardization and competition.

Over another chat, I met Ranga Nathan, a Perl programmer who spends a lot of time with COBOL code. We talked about a decent number of issues, and found an example of a point Nat Torkington made during one of his talks. When Perl doesn't go whole-hog into OOP or CORBA, it could be a sign that these bloated technologies are really unnecessary for solving real-world problems. People like Ranga who are coming out of the glass house of mainframes are coming into Perl and skipping pass objects and multithreading, and finding themselves happy and productive using Perl, ignoring all of the hype that comes with other languages.

Mark-Jason Dominus

I don't really remember much of what happened at YAPC. I took the redeye in from San Diego and arrived at about 6 AM the morning that the conference began. Kevin told me that Joe had been delayed, and asked if I would fill in for him, and for some reason I said "yes." I suppose part of the reason is that I don't get very many opportunities to give my talk on how Strong Typing Doesn't Have to Suck. I think the talk went really well, because it requires that I jump up and down and froth at the mouth and scream about how awful the type checking in Pascal is, and it turns out that it's a lot easier to do that when I've just come in on the redeye from San Diego.

The rest of the conference was a big blur for me. I gave twelve hours of talks in two days, and then I made a midnight excursion with Abigail to obtain the gong for the Lightning Talks. The next day I was signed up for paintball, and as we were waiting for people to finish assembling so we could leave, I suddenly realized that it just wasn't going to happen, and I got my money back.

One of the paintballers took this picture just before they left:

Picture credit: Paul Blair

This Week on p5p 2000/07/09


NEW! RDF Available

Starting with last week's report, you can get an RDF for each report by replacing the .html in the filename with .rdf.

The current report will always be available from http://www.perl.com/p5pdigest.cgi. The RDF for the current report will always be available from http://www.perl.com/p5pdigest.cgi?s=rdf.

You can subscribe to an email version of this summary by sending an empty message to p5p-digest-subscribe@plover.com.

Please send corrections and additions to mjd-perl-thisweek-YYYYMM@plover.com where YYYYMM is the current year and month.

Next week's report will be a little early, because I'm going to try to get it out before the big Perl conference. Then the following report will be a little late, because I will have just gotten back from the big Perl conference.

Bug Database

Alan Burlison reporterd a minor bug in h2xs, and pointed out that it had been fixed betwen 5.005_03 and 5.6.0, and also that there were at least three open tickets in the bug database that appear to have been resolved by this fix. He suggested that the database support an interest list for each bug, and send mail to everyone on the interest list when there was a status change for their bug. Richard Foley said he would look into this.

This led to a large discussion about the bug database and bug tracking generally. Simon said that he thought the entire bug system needed a complete overhaul. Specifically, he said he wanted to see the two (or three) bug databases replaced by a single database; ownership of tickets by people who are addressing the bugs, with automatic reversion to the `unowned' pile if the owner doesn't take some periodic action such as responding to an automatic email; weekly automatic reports to p5p on outstanding tickets and to ticket owners.

Richard Foley replied that some of this is in progress, or is easy. For example, other bug databases can send email into his perlbugtron to enter their bugs there. Also he can set up a cron job to sent p5p a weekly status report. But it's not clear that such a report would be useful unless someone cleas up the existing database, checking over all the outstanding bugs, closing the ones that are fixed in 5.6.0, weeding out the non-bugs, merging reports that appear to be the same bug, and soforth. Nat Torkington mentioned that he had started to do this a few months ago, but stopped, because the job is so big.

Nat then pointed out that this would be a good way for beginning p5p people to gain expertise. Sarathy agreed that the biggest problems appeared not to be technical, but that there is no bug champion who has taken responsibility for taking care of the database. I mentioned that I had been planning to take this up after the conference this month, and had been moving into the job stealthily by reportong on open bugs in these reports, and encouraging people to try to fix them. Several people volunteered to help categorize bugs and close tickets.

Alan Burlison described his imagined bug lifecycle.

Summary of Alan's ideas:

  1. The bug is reported.

  2. The bug is routed to the 'triage' person for its category.
  3. A registered bugfixer is assigned the bug from a queue or unassigned bugs.
  4. The bugfixer fixes the bug and mails in a patch.

Simon suggested that one way to prevent the problem from getting worse is to let people close tickets by email. If a bug fixer cc's their patch to an address like close-##bugid##@bugs.perl.org, that could automatically close the ticket. Richard appeared to be willing to support this.

Simon also mentioned that he is starting up a web site for discussion of the Perl source code and internals and nurturing of new Perl core hackers.

There was some discussion of alternate bug tracking systems, including Debian's, which is reputed to be good, but the consensus seemed to be that it was not appropriate for Perl.

Root of this thread.


Jarkko did some work on pod/buildtoc, which is the program that constructs the perltoc man page. He made a long list of pods that had been added but which were not in buildtoc's list of files to include. Jesús Quiroga sent his list of pods that are in the 5.6.0 distribution---there are 326 of them. There was some discussion about what to do with the many miscellaneous and platform-specific items, but no clear conclusion.

Jarkko also reordered the brief table of contents that is in perl.pod. I am glad; it was always embarassing to be teaching a class of Perl beginners, to proudly say ''Look, if you do man perl you get a list of the other manuals,'' and then to see three different versions of perldelta there at the top of the list. There was a little discussion about how to order the items, and about whether or not perlbook.pod should remain in the distribtution.

use namespace

Alan Burlison wants to be able to say

        use namespace Sun::Solaris;

and then have

        my $obj = Foo::Bar->new(...);

be interpreted as if he had written

        my $obj = Sun::Solaris::Foo::Bar->new(...);

instead. This is very similar to a suggestion that Michael King made last year, except that Michael also had some other ideas that were unpalatable.

Previous discussion.

Alan said he would be willing to try to implement this, but first he wanted to hear people's comments about whether it was advisable.

Graham suggested that the namespace pragma would not modify the meaning of constructions like this:

        my $obj = Foo::Bar->new(...);

but rather, only those that looked like this:

        my $obj = ::Foo::Bar->new(...);

Then you would still be able to use other modules, even in the scope of use namespace. He also pointed out that to work properly it would have to have a lexical scope. A bunch of other possible semantics were discussed, all of which seemed to me to be obviously The Wrong Thing.

There was a tangent discussion about the uses of __PACKAGE__.

Unicode Input Solution

Simon reported a clever suggestion from the Perl-Unicode mailing list. Some systems, such as Windows, store system data like directory entries in unicode. You'd like to flag such inputs as UTF8 when they are read in. The suggestion was to piggyback this atop the tainting mechanism. At present, there's a macro which, if taint mode is on, turns on the taint flag on the input scalar for every input Perl reads from any source. Simon posted a patch which extends the macro so that if use utf8 is in scope, and the string is a valid UTF8 string, Perl will also set the UTF8 flag on the scalar. Since presumably everything is already checked for taintedness when it's read in, this automatically puts the check for UTF8-ness everywhere also. Read about it.


I reported that this is equivalent to tr/a-y//, because the ranges are expanded inline from left to right, so the original tr becomes tr/abcdefghijklmnopqrstuvwxyz-0//, and then the z-0 is discarded (because there are no characters between z and 0. Sometime later, I sent a patch, and also sent a patch that forbids X-Y when X occurs after Y. The latter was already a fatal error in a regex character class; it turns out that the code for range parsing in tr is totally separate from the analogous range parsing code for regexes.

Patch #1. Patch #2.

Mutual use

Alan Burlison wanted to know what to do when he needs to have two modules, each of which uses the other. Various solutions were proposed, mostly of the form 'Don't do that'. THe currect answer in Alan's case was to factor out the part of B that was needed by A into a separate module, C, and have A use C and B use A.

sprintf tests

Sarathy pointed out a problem with Dominic Dunlop's excellent sprintf tests: Not all systems produce output with exactly two digits of exponent information, so many tests fail on Windows systems, for example. (The C standard only requires that there be at least two digits.) Dominic said he would think about what to do about this, but has not said anything about it since then.

Complex Expressions in Formats

H. Merijn Brand fixed a bug that he reported last month: Complex expressions like $h{foo}[1] were misparsed when they appeared in format lines.

Original bug report

The patch.

Thank you very much, Merijn!

Threading Failure Test Case

Lincoln Stein sent a smallish program that hangs inside the thread library. Persons wishing to be deemed heroic should investigate this.

Test case.

What does changing PL_sh_path do?

Bryan C. Warnock asked what would happen if he were to change PL_shell_path to point to some shell that was not Bourne-compatible. Nobody answered, possibly because nobody has tried before.

If Bryan reports back later I will mention it.

UNTIE Method

Brian S. Julin expressed a wish for an UNTIE method which would be called automatically when you untie a tied variable. I said I had wanted such a thing for a long time (since at least early 1998, apparently) but I did not provide a patch.

Sarathy Fixes a Bug that Nobody Knew Existed

Several, actually. Mostly memory leaks.



A large collection of bug reports, bug fixes, non-bug reports, questions, answers, and a small amount of spam. The only flames were from that idiot who can't figure out how to unsubscribe. I'm sure you've met him before.

Until next week I remain, your humble and obedient servant,

Mark-Jason Dominus

This Week on p5p 2000/07/02


You can subscribe to an email version of this summary by sending an empty message to p5p-digest-subscribe@plover.com.

Please send corrections and additions to mjd-perl-thisweek-YYYYMM@plover.com where YYYYMM is the current year and month.

More Unicode

Simon continues to generate Unicode patches.


More tests.

Patch and request for help.

Patch that fixes concatenation operator.

Torture tests.

Unicode Handling HOWTO

Simon wrote a clear and amusing summary of what Unicode is and how to deal with it. If you've been puzzled by all this unicode stuff, you should certainly Read about it.

Unicode Regex Matching

Simon also asked what would happen if you did this:

        $b = v300
        v196.172.200 =~ /^$b/;

(This is an issue because the UTF8 representation of $b is actually the two bytes with values 196 and 172.) But Gisle said that of course it should not match, because the target string does not in fact contain character #300.

This led to a brief discussion of what the regex engine should do with UTF8 strings. The problem here goes back to the roots of the UTF8 implementation.

Larry's original idea was that if use utf8 was in scope, operation would assume that all data was UTF8 strings, and if not, they would assume byte strings. This puts a lot of burden on the programmer and especially on the module writer. For example, suppose you had wanted to write a function that would return true if its argument were longer than 6 characters:

        sub is_long {
          my ($s) = @_;
          length($s) > 6;

No, that would not work, because if the caller had passed in a UTF8 string, then your answer ouwld be whether the string was longer than six bytes, not six characters. (Remember characters in a UTF8 may be longer than one byte each.) You would have had to write something like this instead:

        sub is_long {
          my ($s) = @_;
          if (is_utf8($s)) {
            use utf8;
            length($s) > 6;
          } else {
            length($s) > 6;

This approach was abandoned several versions ago, and you can see why. The current approach is that every scalar carries around a flag that says whether it is a UTF8 string or a plain byte string, and operations like length() are overloaded to work on both kinds of strings; length() returns the number of characters in the string whether or not the string is UTF8.

Now here's a dirty secret: Overloading the regex engine this way is difficult, and hasn't been done yet. Regex matching ignores the UTF8 flag in its target. Instead, it uses the old method that was abandoned: if it was compiled with use utf8 in scope, it assumes that its argument is in UTF8 format, and if not, it assumes its argument is a byte string.

The right thing to do here is to fix the regex engine so that its behavior depends on whether the UTF8 flag in the target. The hard way (but the right way) is to really fix the regex engine. The easier way is to have the regex engine compile everything as if use utf8 was not in scope, and then later on if it is called on to match a UTF8 string, it should recompile the regex as if use utf8 had been enabled, and stash that new compiled regex alongside the original one for use with UTF8 strings.


Jarkko posted a link to an excellent Perl I18N/L10N FAQ written by James.

Read about it.


This led Simon to ask if Perl should have support for normalization. What is normalization? Unicode has a character for the letter 'e' (U+0065), and a character for an acute accent (U+00B4), which looks something like ´ and is called a 'combining character' because it combines with the following character to yield an accented character; when the string containing an acute accent is displayed, the accent should be superimposed on the previous character. But Unicode also has a character for the letter e with an acute accent (U+00E9), as é. This should be displayed the same way as the two character sequence U+00B4 U+0065.

Perl does not presently do this, and if you have two strings, produced by pack "U*", 0xB4, 0x65 and by pack "U*", 0xE9 it reports them as different, which they certainly are. But clearly, for some applications, you would like them to be considered equivalent, and Perl presently has no built-in function to recognize this.

More complete explanation.

Sarathy said yes, we do want this, but not until the basic stuff is working.

Simon Stops Working on Unicode

Simon announced a temporary halt to his Unicode activities; he is going to work on the line disciplines feature next.

He also said that he would be happy if someone would help him with both Unicode and line disciplines.

Speeding up method lookups

Previous summary.

More previous summary.

Fergal Daly pointed out that Doug's patch will break abstract base classes, because it extends the semnatics of use Dog $spot to mean something new. Formerly, it meant that $spot was guaranteed to be implemented with a pseudohash, and that the fields in $spot were guaranteed to be a subset of those specified in %Dog::FIELDS. Doug's patch now adds the meaning that method calls on $spot will be resolved at compile time by looking for them in class Dog. This is a change, because it used to be that it was permissble to assign $spot with an object from some subclass of Dog, say Schnauzer, as long as its fields were laid out in a way that was compatible with %Dog::FIELDS. But now you cannot do that, because when you call $spot->meth you get Dog::meth instead of Schnauzer::meth.


Some discussion ensued. Sarathy suggested that the optimization only be enabled if, at the end of compilation, Dog has no subclasses. Fergal said it would be a shame to limit it to such cases, and it would not be much harder to enable the optimization for any method that was not overridden in any subclass.

Discussion is ongoing.

my __PACKAGE__ $foo

Doug MacEachern contributed a patch that allows my __PACKAGE__ $foo, where __PACKAGE__ represents the current package name. There was some discussion about whether the benefit was worth ths cost of the code bloat. Doug said that it was useful for the same reasons that __PACKAGE__ is useful anywhere else. (As a side note, why is it that the word 'bloat' is never used except in connection with three-line patches?)

Andreas Koenig said that it would be even better to allow my CONSTANT $foo where CONSTANT is any compile-time constant at all, such as one that was created by use constant. Doug provided an amended patch to do that also.

Jan Dubois pointed out that this will break existing code that has a compile-time constant that is of the same name as an existing patch. Andreas did not care.

Andreas Koenig: Who uses constants that have the same name as existing and actually used classes isn't coding cleanly and should be shot anyway.

More persuasively, he pointed out that under such a circumstance, my Foo $x = Foo->new would not work either, because the Foo on the right would be interpreted as a constant instead of as a class name.

Andreas' explanation of why he wants this feature

Doug then submitted an updated updated patch that enables my Foo:: $x as well.

Final patch.


Last week I sent aggrieved email to a number of people asking what cfgperl was and why there appeared to be a secret source repository on Jarkko's web site that was more up-to-date than the documented source repository. I was concerned that there was in inner circle of development going on with a hidden development branch that was not accessible to the rest of the world.

Jarkko answered me in some detail in email, and then posted to p5p to explain the real situation. cfgperl is simply the name for Jarkko's private copy of the source, to which he applies patches that he deems worthy. It got ahead of the main repository because Sarathy was resting last month.

Jarkko's full details.

Missing Methods

Richard Soderberg responded to my call for a patch for this (see last week's discussion) and produced one. Thank you very much, Richard!

The patch.

Signals on Windows

Sarathy said that signals really couldn't be emulated properly under Windows, but that people keep complaining about it anyway. So he put in a patch that tries to register the signal handler anyway, I guess in hopes of stopping them from complaining.

Read about it.

New File::Spec

Barrie Slaymaker submitted a set of changes to the File::Spec suite.

The patch.

More patch.

Another depressing regex engine bug

This can result in backreference variables being set incorrectly when they should be undef. Apparently state is not always restored properly on backtracking.

Read about it.

s/// Appears to be Slower

Perl Lindquist reported an example of s/// that runs much slower in 5.6.0 than in 5.004_03. The regex is bad, so that you would expect a quadratic search, but Mike Guy reported that in fact Perl was doing a cubic search.

Mike's analysis and shorter test case


Simon claims that this document is three years old and that he was only sending a minor update, but I don't find it in my copy of the development sources.

It is a document about how to use the Perforce repository in which the master copies of the Perl sources reside.

Read about it.

\& prototype now works

Larry sent a patch that permits a function to have \& in its prototype. It appears to be synonymous with &.

Call for Short Doc Patch

The sequence \_ in a regex now elicits a warning where it didn't before. Dominic Dunlop tracked down the patch that introduced this and pointed out that it needs to be documented (in perldelta and possibly perldiag) and probably also needs a test case. But nobody stepped up. Here's an easy opportunity for someone to contribute a doc patch.

Read about it.

More Bug Bounty

Dominic Dunlop reported an interesting bug in the new printf "%v" specifier. The bug is probably not too difficult to investigate and fix, because it is probably localized to a small part of Perl that does not deal woo much with Perl's special data structures. So it is a good thing for a beginner to work on. Drop me a note if you are interested and if you need help figuring out where to start.

Read about it.

sprintf tests

Dominic also sent a patch that added 188 new tests to t/op/sprintf.t.

The patch.

Regression Tests and @INC setting

Some time ago, Nicholas Clark pointed out that many regression tests will fail if you opt not to build all of Perl's standard extension modules, such as Fcntl.

Previous discussion.

A sidetrack developed out of Nicholas' patch to fix this, discussing the best way to make sure that tests get the test version of the library, and not the previously installed version of the library. Nicholas was using

        unshift '../lib';

This is a common idiom in the test files. What's wrong with it? It leaves the standard directories in @INC, which may not be appropriate, and it assumes that the library is in a sibling directory, so you cannot run the test without being in the t/ directory itself.

There was a little discussion of the right thing to do here. Mike Guy suggested that one solution would be to have the test harness set up the environment properly in the first place. The problem with that is that then you can't run the tests without the harness. (For example, you might want to run a single test file; at present you can just say perl t/op/dog.t or whatever.)

Sarathy pointed out that having each test file begin with something like

        BEGIN { @INC = split('|',$ENV{PERL_TEST_LIB_PATH}
                                          || '../lib') }

might solve the problem. Then the harness can set PERL_TEST_LIB_PATH but you can still run a single test manually if you are in the right place.

asdgdasfasdgasdf;jklaskldhgauklhc dhacb;dh

Another garbage bug report from the Czech republic. It was funny the first time; this time it is substantially less amusing.

Hey, Czech dude! Stop using perlbug to test your keyboard cables, or I will come to your house and chop off all eight of your fingers.


A large collection of bug reports, bug fixes, non-bug reports (you can use a number as a reference!) questions, answers, and a small amount of spam. No flames.

Until next week I remain, your humble and obedient servant,

Mark-Jason Dominus
Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en