2011Q2 Grant Proposal: Port pmtools to Perl 6

Category: Grants

Comments (5)

What tools will you use for parsing Perl 6 POD? Or do you plan to write your own? What good is a pfcat when there's no perlfunc document for Perl 6?
What tools will you use to obtain export lists from a module? Are you going to handle versioned module dependencies? Can you elaborate on the meaning of site_perl in the context of Perl 6?

I like the idea, but the proposal doesn't seem to reflect fundamental differences between Perl 5 and Perl 6.

1) So the Perl 6 pmtools remain a lightweight toolset, I plan on writing the POD parsing code myself. pmtools was never designed to have a presentation-quality POD parser -- it was designed to quickly and easily get the relevant POD information from the Perl and POD source files. Though someone could prove me wrong, Perl 6 POD (from my looks at it) was designed to be just a step up from Perl 5 POD, not a huge departure.

2) pfcat will be useful when there is Perl 6 perlfunc, as we Perl 6 programmers will eventually need.

3) Though I don't remember the syntax off-hand, I think you can just ask a Perl 6 modules for its exports, rather than parsing the module code as the Perl 5 pmtools must. (And we have better support for parsing Perl 6 than we have for parsing Perl 5.)

4) My long-term plan is to support versioned module dependencies, though last I looked no one had supported versioned modules in their module code yet.

5) Assuming that no one comes up with a better mechanism, site_perl for Perl 6 will contain the Perl 6 modules that are installed after the initial Perl 6 installation. Have you heard anything different about plans for site_perl in Perl 6?

6) I don't see huge differences in Perl 6 vs. Perl 5 except for features designed for better programming-in-the-large -- the standardized object model, flexible multi-method dispatch, built-in Perl 6 parsing support, etc. I am curious to know where you think Perl 6 is different enough from Perl 5 that the general pmtools approach -- small, lightweight tools that do just enough to get developers the information they need -- will fail for a Perl 6 pmtools.

7) Though I did not state this explicitly in my grant proposal, I am aware that Perl 6 is different from Perl 5, so the pmtools porting process is not just like moving a C program from a 32-bit little-endian Unix machine to a 32-bit little-endian Linux machine -- there may be Perl 6 differences from Perl 5 that require a different approach to the particular Perl module development problem than taken by the corresponding Perl 5 pmtool program. But the pmtools are a "gist extraction machine" as it were -- designed to get developers the module information they need without a lot of fuss (or intense, complex coding efforts on the part of the pmtools developer). If you want tools suitable for building presentations about multi-billion dollar (euro, etc.) projects, you may want to look elsewhere. But if you want to check a current module's version, find a module's code to check how it handles an edge case, etc. then the pmtools are a good fit.

currently, I'm -1 to any grant on Perl6 that is not related to the core improvement of rakudo or parrot.

This proposal seems a tad premature. pmtools works in Perl 5 because it builds on the existing module infrastructure. There isn't much of a module infrastructure for Perl 6 yet.

Rather than copy a set of tools that were designed to solve a set of Perl 5 problems in a Perl 5 universe, better would be to let the Perl 6 universe evolve its own tools that solve whatever problems come up as it evolves its own module system. (IMHO, of course)

I'm curious as to what you would like to see in Perl 6 module infrastructure, as we already have 90+ Perl 6 modules at http://modules.perl6.org/.

As Perl 6 developers, we are the agents of evolution -- Perl 6 module tools will not evolve without someone making them evolve. I'm trying to get ahead of the game here, so we do better than we did with Perl 5 (when (I think) there were over 1000 modules in CPAN when Tom Christiansen wrote the first version of pmtools).

Perl 6 is an advance (a large one) over Perl 5, but we will still store our source code in files, our source will still use explicit versioning, we will still document with POD, etc. -- all of which bring their own issues to the table. Rather than forcing a huge infrastructure on each and every module so you could just ask that module for all of its information, it would be better to have a set of loosely-coupled tools to help developers find the information they need about modules -- hence pmtools.

Perl (5 or 6) is not a huge, tightly-coupled system like a LISP or a Smalltalk. Perl is closer to the Unix/Linux command-line tool set or much of the Web infrastructure, with numerous tools communicating with each other over a standard set of protocols. Creating pmtools as a separate set of tools is closer to that style of architecture.

I think it is worth reflecting on Gall's Law here -- "A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system." pmtools is a simple system of tools for dealing module metadata.

Sign in to add comment