[Haskell-cafe] Re: Hackage on Linux
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Fri Aug 27 08:09:35 EDT 2010
On 27 August 2010 21:40, Andrew Coppin <andrewcoppin at btinternet.com> wrote:
> Ivan Lazar Miljenovic wrote:
>> 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
> 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
>> 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.
> What all this proves is that XML can be horrid, or it can be just fine.
> Personally, I would have no problem with writing
> <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:
>> (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...
> 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 at gmail.com
More information about the Haskell-Cafe