>
> 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 Karasik
