Re: [p5pod] [ANNOUNCE] Pod::StdParser, Pod::Tests proof of concept

[Marek Rouchal DAT CAD HW Tel 25849]

On Wed, 6 Sep 2000, Barrie Slaymaker wrote:

BS> and that forcing people to use that [ OO ] as a
BS>tool is adding a performance penalty (certainly in the single-pass case)
BS>and adding a barrier to entry in the form of an increased learning curve.

We probably could argue for centuries about this - personally I find the
OO approach very well suited for this type of task and it even may seem
the more natural approach - but really, I don't want to continue this
particualr discussion.

BS>We agree.  One possibility is that Pod::Compiler should be factored into 
BS>two components: the parser engine (perhaps migrating stuff to Pod::StdParser
BS>or Pod::Parser), and the tree builder.

This sounds reasonable to me.

BS>  The cmd_ and seq_ dispatching
BS>I'm borrowing and extending (a bit) from Russ's Pod::Text allow easy addition
BS>of extensions just by declaring new cmd_...() or seq_...() methods, so that
BS>subclassing Pod::Compiler (if it becomes is-a Pod::StdParser) to create
BS>compilers for POD superset languages should be easy, too.
BS>
BS>It looks like all that you would need to do to inherit from Pod::StdParser
BS>is split command() and delete a bunch of warnings.  I need to add a few
BS>more warnings to Pod::StdParser, but most are already there.

I would not want to delete the warnings, I'd prefer an option to suppress
them or a configurable handler to deal with them (like poderror in
Pod::Parser). It'd be great if the tree builder would get next-to-correct
bits that have already been cleared of the most mistakes a POD author
made.
Pod::Compiler then would do additional checks for proper nesting of =item
in =over/=back and creating appropriate trees from these commands.

BS>If you can show significant speed gains without requiring gobs of
BS>memory or disk space (I know I admin some systems with little spare room
BS>to cache all those Storable objects: clients' systems where hardware upgrades
BS>don't come easy) , no matter how it works internally (DOM, SAX, or infinite #
BS>of monkeys hacking perl), I think people will want it.

Ok, memory usage is an issue. However, with the "Storable" approach we'd
need to keep only the contents of a single POD file in memory at a time,
and this scales with the size of the POD file itself:

$ wc  /opt/perl_5.6.0/share/lib/pod/perlfunc.pod
5781   34945  224807

As this is one of the largest POD files I've seen, I think everybody with
16M of RAM can easily cope with this. And storing the Storable objects
cannot be a problem: They'll be much smaller than the actual destination
files. This means, if you have room for the destination files, you'll have
enough for the Storable objects as well.

BS>But a simple event-driven Pod::Parser derivative is needed for simpler needs.

Sigh. I guess I have to agree ;-)
However I'd like to ask you to check how fast Pod::Compiler is and whether
you could live with that.

Still a compromise might be having a separate Parser and Tree builder,
with the Parser already checking more than the plain structure.

Last but not least: I wonder when I'll have some time left for actually
coding all this ;-)

-Marek