Front page | perl.pod-people |
Postings from October 2020
> > Hm, using =begin/=end as an extension mechanism is an interesting idea. > It's unfortunate that limitations in the existing mechanism mean that a > formatter still has to understand the extension to show the fallback text, > but that may not be a significant problem. Agree > I think there is some merit to making your YAML-inspired syntax just be > YAML if you go down that route so that parsers can reuse a YAML parser, > although I understand why the complexity of YAML isn't appealing, and that > also has weird implications for Perl core since introducing a YAML module > into Perl core is going to be unappealing, but POD parsing currently lives > in core. I actually like to go full YAML to make that easier to implement and adopt. Indeed it is a tactical question what to do with the YAML parser, but I think the following trick can be done: - Since Pod::Parser doesn't know that =image or whatever else is YAML, it doesn't need to require it. I would be nice though, to have a hash passed down to a formatter, but that requires YAML in the core, so let's don't look that way just yet. - XHML or other backends don't need YAML.pm and friends either because it knows that it can only understand top-level data, no arrays or subhashes or anything. So a rudimentary parsing is enough. I don't think YAML, or YAML::PP will ever make it to the core due to the modules' sheer size, - JSON::PP is a single file. But a minimal Pod::YAML is quite feasible; and if it will be spec-complete, or at least complete enough to skip the subarrays and subhashes, then the step 1 can be extended to the benefit of all backends. -- Sincerely, Dmitry KarasikThread Previous | Thread Next