* Anything else that should go into the requirements?
It would be even cooler if the command $ p6explain 'some_user_defined_sub' would display prettily-formatted pod for that sub and would work transparently, regardless of whether this sub is defined in the Perl standard library, CPAN module, or user's own code. And if there are several modules that have a sub with this name - print a list of modules (sorted by relevance to context or alphabetically) and let the user select what he wants. An overloaded operator should be the same thing as a sub for this matter. Rationale: Perl 5's perldoc displays the pod for every properly installed and documented module just as if they were perl* manpages and it is transparent to the user. That's one feature of Perl 5 that i absolutely admire. Why not enhance it to smaller units, like subs? And it doesn't break the "different things should look different" philosophy, as these look different enough to me: $ p6explain 'some_user_defined_sub' # sub $ p6explain Date::Hebrew # an imaginary module $ p6explain := # operator $ p6explain any # builtin $ p6explain perlrules # an imaginary P6 manpage that will replace perlre
* Is it useful at all?
Very much so, yes. That's what makes Redmond's development tools so attractive - you can put the cursor on any word, press F1 and get all the help. It doesn't work so well with operators, and with user-defined functions it just fails; but for user-defined functions it has the "reference" feature, which takes the user to the place where the functions is defined (if he's lucky enough to have the code). Actually i see no reason why this couldn't be combined with the help - for me the function's code and its documentation in a human language are usually equally important. Integrate that tool with Emacs, and you've got a self-documenting Perl 6 IDE ;)
* Is it possible to implement it satisfactory without building a p6 compiler?
Syntax highlighters work even with code that doesn't necessarily compile, so probably the answer is yes. But if this tool could peek into the compiler's syntax tree and see all the namespaces that the compiler knows as an easy-to-navigate data structure, then implementing my wish from above - generically getting help for every token wherever it is defined - would probably be easier. (Too bad i don't really know much about implementing compilers.)
* Do you have a good idea for a project name?
I really wish that such project just DIDN'T have a name, at least not at the end-user level. If it will have a name, there's a chance that it will join the army of Free Software programs with awful names such as YELP. It can just be a part of perldoc - that's one good name.
