On 9/6/2010, Petr Rockai wrote:
PS: I find it curios, if somewhat amusing, how nothing happened with the
annotate output for a couple years, until someone re-implements it with
a new output format. All of sudden, everyone has an opinion on how
should the output look...
I think I've been rather consistent on this topic. I've stated before
that I would be happy if the XML support is made better/more valid. But
the reason we've been splitting hairs so long on this particular subject
this time around is because we are discussing the dropping/removal of
--xml support and if such a thing happens I have been commenting on my
thoughts for hopefully making sure that the machine-readable output
stays *at least* as useful as --xml, if not *more so*.
"Stephen J. Turnbull"<step...@xemacs.org> writes:
But by now there are freely available YAML parsers for pretty much any
language but shell, no? ISTM that if people are doing anything that
requires actually interpreting non-ASCII strings or other "hard to
read" output, they probably don't want to be doing it in shell anyway.
At least my experience on the Mac has been that non-ASCII file names
often don't work as you'd expect in shell (and shell quoting of file
name variables whose values might-or-might-not contain spaces is a
real headache, too).
The Official YAML spec page gives a mostly decent overview of the major
parsers. Unfortunately it doesn't do a great job of pointing out the
supported nature of them. (The two under C#/.NET for instance: one is an
under-documented student work that hasn't been maintained and isn't up
to date, and the other is an in-progress work that isn't completed yet.)
In my experience, though, the "core" parsers in C, Python, Ruby, and
Perl all are more than adequate and generally well-supported. Python,
Ruby, and Perl are increasingly common shell scripting languages at this
point, and it seems a reasonable assumption to me that someone doing
shell scripting will know at least one of those and will have access to
one or more of that language's YAML parsers...
There isn't one (that would be at least basically documented) for
Haskell. I imagine that's the case for majority of languages in
fact. (Majority in number of languages, not users.)
I find the YAML packages on hackage quite fascinating, myself.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/YamlReference
That seems to the "the" reference parser for the YAML specification from
which all others are supposedly built. Nice to see that it is Haskell.
But we aren't interested as much in parsing so, moving down the list we
have two big ones:
http://hackage.haskell.org/package/yaml
http://hackage.haskell.org/package/HsSyck
Interestingly, both of these of are parser/emitters and both bind a C
API, libyaml and libsyck respectively. Both C APIs are event-oriented
stream parsers (SAX and its derivatives being the obvious comparison
from the XML world), with libsyck being the older, deprecated YAML
library and libyaml the current standard. HsSyck is a product of the
Pugs project and yaml is seemingly lone effort, hosted on github. HsSyck
tries to do a little bit of wrapping of the stream structure into to
more conceptual data structures whereas yaml sticks to the low-level
event structure...
I'm thinking about using this an excuse to write some more Haskell, so I
may take one of these two (probably yaml) and write some code with it.
I'll keep darcs in mind as a potential consumer of whatever my efforts
might be.
--
--Max Battcher--
http://worldmaker.net
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
