[Haskell-cafe] Re: Hackage on Linux

[Ivan Lazar Miljenovic]

On 27 August 2010 21:40, Andrew Coppin <andrewcoppin at 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.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com