On Sun, 9 Dec 2001, Sean M. Burke wrote: > Now that perlpodspec has (hopefully) come to clear up some of the nastily > hazier aspects of Pod processing, I have starting wondering: what next? > And the answer I keep coming up with is this: writing a new Pod parser > module, basically from scratch, having it be perlpodspec-compliant from the > get-go, and having that be the canonical spec-compliant Pod parser.
<devil's advocate> Why? What is wrong with Pod::Parser that can not be fixed by some improved documentation and examples? Pod::Parser can generate parse trees. As someone who battled with Pod::Parser to implement Pod::LaTeX I can attest to the fact that the learning curve was a little difficult but Pod::Parser does do the job and do it well. A little more explanation and examples in the documentation would have made it a lot easier for me. Is Pod::Parser so bad that it can not be made to be perlpodspec-compliant? Why not simply fix Pod::Parser? Pod::ParseUtils can be modified to support the new link formatting - presumably with a fairly minor patch (esp if it usees Pod::ParseLinks). I really need to be convinced that the gains in replacing Pod::Parser are worth it all? The effort would be better spent fixing up Pod::HTML so that it uses Pod::Parser. We already have a canonical pod parser. It works. It will be a lot of effort to rewrite podlators and the other pod processors that are based on it. What is the gain? </devils's advocate> > > That begs the question: what should its interface look like? If it's > tree-based, what grammar would describe the trees it generates, and would > the node class interface look like? If it's event-based, what how should > its events differ from Pod::Parser's events? And how do I decide whether > to make it tree-based or event-based? One surprising thing I've learned is > that some people strongly prefer tree-based parsing systems, whereas other > people strongly prefer event-based parsing. Give them both then. Once you have an event based parser you can easily set up the callbacks to provide a tree structure. > > The solution that most appeals to me currently, is to make this > hypothetical module take Pod as input, and spit out XML as output, which > the author of a Pod processor would then direct to whatever Pod parser he > prefers. This obviates most of the above-mentioned problems. > Specifically, people who like event-based processing would direct the > output stream to an event-based XML parser, and those who like tree-based > processing would direct it the tree-based XML parser of their choice. One > of the nice things about XML is that with it, there's only a notational > difference between processing models where every token generates an event, > and tree-based processing models. Moreover, this avoids having to actually > write and maintain a Pod-specific tree node class. Plus there's safety in > numbers, since everyone and their dog is processing XML these days, so It > Has To Work. > I'm a big fan of XML and this sounds interesting in its way but also a bit bizarre. For this to work Perl would have to ship with an XML parser. A pod to xml translator is a good thing but should we be using XML as our base format for parsing? -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj
