On 27 August 2010 21:40, Andrew Coppin
Ivan Lazar Miljenovic wrote:
I would point out what happened with X configuration recently: they went from an ini-style configuration file that was relatively human readable and editable (especially if you were basing your config off of a guide) to an XML-based one when they switched to HAL-based device management (since XML is easier for programs to read and write) and back to the original format because the XML-based format was a disaster.
Doesn't necessarily prove anything. It's much like saying "a know a guy who switched from a diesel to a petrol car, and it was a disaster, therefore we should ban all petrol cars". Your argument does not follow.
True; I was just providing one example of something switching to a "better" format (and actually I don't think it was the pain of XML that forced the change back, but the fact that HAL is going to be deprecated).
I personally find a file format such as Cabal's much easier to read and write than one that requires me to put a whole bunch of angled brackets in everywhere...
I find (X)HTML just fine to read. MathML, on the other hand, is a disaster.
However, (X)HMTL is designed to convey text, not metadata. An XML/JSON version of Cabal would (probably) have a higher ratio of angled brackets, etc. than a typical HTML document would.
[snip]
What all this proves is that XML can be horrid, or it can be just fine. Personally, I would have no problem with writing
<Name>foo</Name> <Version>1.0</Version> <Synopsis>This does stuff.</Synopsis>
Now I don't have to worry about whitespace; XML has rules for all that. And I don't have to worry about escaping or character sets; XML has rules for that too. And if that's too hard to swallow, how about JSON?
{ "Name": "foo", "Version": 1.0, "Synopsis": "This does stuff." }
Well, the JSON is definitely easier to read than the XML, but I would much prefer a really, really small signal to noise ratio. If we have to specify some more syntactic rules into .cabal, why not follow Haskell syntax for lists, etc.? Admittedly, Haskell has no multi-line String support which would make defining something like the "Description" field harder...
Again, I can now lay this out any way I want, and it's really pretty easy to read. About the only unfortunate feature is that the key names have to be quoted for some reason.
Isn't that by definition of JSON? :p
I've done bullet lists; it requires a slight change to the usual:
http://hackage.haskell.org/packages/archive/graphviz/2999.10.0.1/graphviz.ca... (note the `.'s in between lines).
Curly braces and dots? I don't see that documented anywhere. Presumably this is due to the stupid insistence on using whitespace to delimit things. If it were XML or JSON, you wouldn't need such silliness.
Well, you would if you wanted that passed to Haddock... (in that you might escape/unescape things too much/not enough). My guess is that the Haddock-isation of the Description field is a more recent hack to get it to work on Hackage and that was the neatest way they could work out how to do it whilst remaining backwards compatible.
Oh, I definitely agree with you that Haddock's markup leaves a lot to be desired.
The output too. But hey, I guess when I've written somebody better myself *then* I get to criticise...
Yeah... :s
Well, the original design goal was apparently for Cabal packages to get converted into Debian .deb packages, RPMs, MSIs, and so forth, which implies package conversion tools being able to read it.
Well, yes, but Cabal itself is a library so things like hackport, cabal2arch, etc. use Cabal to parse the .cabal file rather than writing their own parser.
And from a brief bit of Googling, Ruby Gems seems to use its own (YAML-based) file format...
YAML is equally horrid. I hate it.
After eventually managing to track down a Gemfile (one nice thing about Hackage: the .cabal files are linked to directly!), I tend to agree. However, it seems to be more akin to a Makefile than a .cabal file, in that there is no extra package metadata there.
Now, Duncan et. al. are working on Cabal-2; it's quite possible that they're taking complaints like this into account, but I would much prefer to keep something like the current format (but with better specifications) than one using XML or JSON.
Now we're just arguing over asthetics.
Besides, we all know the format won't be changed. It would break compatibility. (Man, now I remember why Haskell's slogan is "avoid success at all costs"...)
I believe that they're not going to care too much about compatability wrt Cabal 2; however porting everything is going to be difficult... However, this applies to your argument as well: we can't now switch to JSON or XML because of compatability. However, if you so wished, it might be possible to write an XML/JSON -> .cabal converter so you can write your configuration file in a format you prefer... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com