Log in

No account? Create an account
Champion needed: command-line processing in Perl 6 - Poetry is a good reason

> Recent Entries
> Archive
> Friends
> Profile

September 21st, 2005

Previous Entry Share Next Entry
11:37 am - Champion needed: command-line processing in Perl 6
Despite the flurry of activity around Perl 6 that pugs has created, there is one piece of the puzzle that’s sorely missing, and that is command-line processing. This is a pretty important piece: until it’s provided, people wanting to write useful tools will have to do lots of distracting labor.

As a case in point, consider the PPT project, which ports unix tools to Perl, so that they can be run anywhere. For Perl 5, it had mostly educational and amusement value. In Perl 6, it will still have those, of course, but also higher practicality, because compiled p6 programs will be very fast. The ppt directory in pugs lies almost empty, though, because almost anything in it needs to parse command line args. This is a shame, because almost everything in it will turn out to take a screenful of beautiful code :-)

So what do we need? We need a good getopt library. Its fundamental requirement is to parse both BSD and GNU-style args. Anything else is extra, really, but before you hop along and port the adequate Getopt::Long, please consider how you could do even better. In no particular order:

  • Cleanliness - all the libraries I’ve looked at so far assume the args are in @ARGV. Often that’s what you want, but sometimes, it isn’t. For example, I once had to write a tool that simulated invocations of other command lines, so I really wanted to parse a different array and not have the library make global assumptions for me. (Another place you need this is for your own tests.) I used local to work around this, but that’s ugly.
  • Power - what if your program wants to do alternative command line parsing, like cvs’s command-based tree? Or perl5’s own pragmatic, inconsistent, optimized-for-oneliner-fun command line? Can your favorite lib do that?
  • Specification basis - iproute for example specifies its args very formally—and they don’t look like GNU getopt args—so there ought to be a tool that uses these specs to actually build the parser. Damian’s various Getopt modules recognize that it’s the spec that should drive everything else, because there’s where you can put funky things like “I insist that this arg has to be an odd number”. His latest, Getopt::Euclid, also recognizes the sad fact that docs and code diverge, so it attempts to solve the problem by reading the specification right out of the docs. That’s a great idea for most projects! (But is another global assumption.)
  • Complexity, testability - Since virtually any program needs to parse a command line, a standard arg-parsing library for Perl 6 (or at least, for pugs) will receive a lot of heat. It’s an excellent candidate for Preludification, that is, its code may be precompiled into the pugs runtime, in fact maybe it can be used to parse pugs’ own command line(!). But this means it really must be testable and fixable. Happily, the pugs hacker culture likes to do both.

That said, not everything has to be done all at once. We need something more badly than we need everything. Getting Getopt::Std is a good start - let’s also get some form of long options, and the ball rolling. If you know Perl 5 well and are looking for a project to get started in pugs/Perl 6 with, this may be it!

(call my bluff)

> Go to Top