* 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.

Reply via email to