I finally got around to reading the YAML specification.
OMG WTF BBQ!
It is unbelievably complex. The lower parts are a rat's nest of links to concept definitions, of which there are many. It requires a 3-phase event-based serialization and deserialisation pipeline.
It's like XML, plus 3 or 4 more extra resolution concepts to deal with human readability and choice.
This seems to result in page after page and multi-dozen EBNF statements just dealing with the issues of significant whitespace.
And for something which I'd originally imagined as just dealing with scalars, arrays and hashs, it contains gems like the following.
"A tag shorthand consists of a valid tag handle followed by a non-empty suffix. The tag handle must be associated with a prefix, either by default or by using a “TAG” directive. The resulting parsed tag is the concatenation of the prefix and the suffix, and must either begin with “!” (a local tag) or be a valid URI (a global tag). When the primary tag handle is used, the suffix must not contain any “!” character, as this would cause the tag shorthand to be interpreted as having a named tag handle. If the “!” character exists in the suffix of a tag using the primary tag handle, it must be escaped as “%21”, and the parser should expand this particular escape sequence before passing the tag to the application. This behavior is consistent with the URI character quoting rules (specifically, section 2.3 of RFC2396), and ensures the choice of tag handle remains a presentation detail and is not reflected in the serialization tree (and hence the representation graph). In particular, the tag handle may be discarded once parsing is completed."
In its fully defined form YAML is a very impressive piece of software engineering, and the flexibility and expressiveness is breath-taking. But my god is it a heavy protocol.
In any case, it certainly explain why YAML.pm chews up 4 megabytes (in the debugger at least) of RAM just to load a default dumper and loader and round-trip an undef to a string and back again.
I've got some things I'd like to use it for, mostly utility config file stuff. But even in this age of large available memory, 4 meg is very big for something that isn't the focus of the program and is just doing some little side job.
So as with Config::Tiny and CSS::Tiny, which both replace a heavy 3+ meg module, I'm going to have a shot at a YAML::Tiny, which just implements the things you'd find in a typical META.yml, in as little code as possible.
I'm not sure if it can even be done yet, and I might need to kill it and do a simple event-pipeline YAML::Lite instead, but it's worth a try first.
And if you have a login to my SVN repository, you're welcome to join in and help.
And in a late-breaking update, rumors come to me of someone else's bloat frustrations over Log4Perl stimulating an idea for a Log4Perl-compatible Log::Tiny module