[petsc-dev] YAML patch take 3

[Sean Farley]

> The minimum requirement must be that they are binary and source-level
> compatible. That means that no public symbols can be renamed, no public
> structures can be changed, and no interfaces can be changed. So it basically
> only allows private changes within the same API and non-conflicting new
> APIs.

This patch worries me too much for adding to petsc 3.3 for the exact
reasons Jed wrote. I strongly think it should only be in pets-dev.

On second thought, after reading this patch carefully, there is a
subtle but big change in functionality: the _YAML was private on
purpose. The user should not have to call a whole new function just
for yaml. The vision I had for Weston's code was to pass a yaml string
(in hopes of command line parsing) or a yaml file to already existing
functions and not have to hardcode calling yaml (or json or
some-future-thing).

If this patch could be reworked to have passing a yaml file to
PetscOptionsInsertFile (so that yaml could be in ~/.petscrc) then I
would be +1 for that patch. As is, I'd rather keep the current code
and try to fix it so that _YAML was still private and that current
functions (PetscOptionsInsertFile, etc.) could parse yaml.