On 27 August 2010 21:40, Andrew Coppin <andrewcop...@btinternet.com> wrote: > 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.cabal >> (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.miljeno...@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe