[Haskell-cafe] Re: Hackage on Linux

[Andrew Coppin]

Ivan Lazar Miljenovic wrote:
> On 27 August 2010 20:13, Andrew Coppin <andrewcoppin at btinternet.com> wrote:
>   
>> Windows has more package management facilities than most people realise.
>>     
>
> But that's one specific installer; not a generic package management
> system (in terms of the extra sub-dependencies).
>   

Sure. Windows doesn't give you the "apt-get install foo" and it just 
works thing. As I say, on Windows, most software requires purchase, so 
that model isn't going to work too well. (Yes, you and I know there's 
plenty of free software for Windows, but that's not what the designers 
had in mind when they designed it. Windows predates widespread OSS by a 
decade or two.)

> I've never seen this Foo-1.1 behaviour, unless it's a specific
> patch-level installer that uses the same data.  Note also that this
> isn't automatic: you have to explicitly download Foo-1.1 yourself,
> etc.
>   

It's nice in that you can just download a small patch file rather than 
redownload the whole of Foo-1.1. But I must admit, I've never seen 
anybody actually offer this in practise. So I guess it's one of those 
things that Windows supports but nobody really uses much.

> So, to be more specific, we can state that Windows has a form of
> package management, without an actual package management _system_ such
> as typically found in Linux distributions.
>   

As I say, it doesn't support the "install foo now" thing that Linux 
usually gives you. But on Windows, "install foo" usually being going and 
buying it first.

Note that what you *can* do, in a corporate environment, is make it so 
that every time a user from group X logs in, applications A, B and C get 
automatically installed. Or all the machines in group Y have them 
installed. Or you can "advertise" applications, which (as I understand 
it) puts an icon on the desktop, and the first time you click it, it 
installs the application and then runs it (and subsequent times, 
obviously, it just runs it). And you can make it so that certain 
security or compatibility updates get auto-installed, and all kinds of 
stuff which I haven't seen on Linux. (But then, I don't use Linux in a 
corporate environmnet, and I do use Windows in such. It wouldn't 
surprise me if RedHat or SuSE offer something like this, for example.)

> Ummm, Cabal is a combination of a build system and metadata
> specification for packages; it isn't a package management system or
> even a package manager (hence my previous link to my blog post).
>   

Yeah. That becomes clearer once you read the original design goals, 
rather than look at what it eventually morphed into becomming.

>>> Furthermore, GHC was aimed primarily at teaching and research, and
>>> from my (admittedly limited) experience the IT/CS departments at unis
>>> tend to run Unix/Linux.
>>>
>>>       
>> Depends on what kind of establishment you go to, I guess.
>>     
>
> Oh really?
>   

Yeah, there are places where everything is Windows, and other places 
where everything is Unix. I've heard rumours that some people even use 
the Apple Mac. I guess it depends where you go...

> 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.

> 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.

When you use HTML properly, what you get is plain text with the 
occasional markup interjection. But with MathML, 80% of the text is 
stuff that doesn't even show up on screen, and it utterly obscures the 
meaning of what you're trying to write. MathML is basically 
pre-tokenised data; every single damned token becomes another XML 
element with a bunch of attributes. It makes it drop-dead easy for 
machines to work with, and almost impossible for humans to comprehend or 
edit.

For example, in MathML, "2+2" becomes

  <math 
xmlns="http://www.w3.org/1998/Math/Mathml"><mrow><mn>2</mn><mo>+</mo><mn>2</mn></mrow></math>

which is pretty absurd. Somewhere in there are the 3 characters of 
"information", the rest is all metadata.

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."
  }

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.

>> I especially love the way that none of Haddock's formatting commands seem to
>> work in the Cabal description field, even though everybody keeps telling me
>> "it's formatted with Haddock". Most especially, bullet lists will not work,
>> no matter what I do, and it's really, really annoying me...
>>     
>
> 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.

>> (Haddock is another irritation. It's formatting commands are seemingly
>> random and ad hoc. Put something in quotes, and it happily generates a link
>> to a non-existent module, without even bothering to check whether it exists.
>> Nice...)
>>     
>
> 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...

>>> Otherwise, if you mean actual file paths when specifying extra files,
>>> etc. then that's because it uses Unix-style paths.
>>>
>>>       
>> Unix-style paths are all very well, but if you need to tell Cabal "hey, the
>> headers are in C:\Program Files\Headers", then you end up needing to type
>> C:\\Program Files\\Headers. Which is unecessary (there's no *reason* why it
>> should need escaping, it's just that Cabal is designed that way), but I
>> could live with it if it were documented somewhere.
>>
>> (The fact that you need to twiddle with an existing Cabal package
>> description is a whole other kettle of fish, of course...)
>>     
>
> Huh, I was under the impression that you could just use unix-style
> file paths in a relative fashion with Cabal even on Windows...
>   

Uhuh, and how do you specify whether the files are under C: or D:?

>> If you're only trying to _read_ the file, both of these are pretty
>> self-explanatory. You only need to worry about the technical details if you
>> try to _write_ them. And there are resources across the face of the Internet
>> explaining in minute detail everything you could possibly want to know. For
>> Cabal's home-brew file format, you've got... the terse notes in the Cabal
>> documentation. And that's it.
>>     
>
> And looking up other .cabal files... ;-)
>   

Oh don't even start about that... That's more or less how I figured out 
how Haddock's undocumented "module attributes" feature works. By reading 
the Haddock comments for another package that had them. Unfortunately, I 
didn't write down what I learned, and now I've forgotten, and decided 
it's not worth the effort to boot!

> Then again, even if we used XML or JSON we'd still have to look up
> what the write tag-names, etc. are.
>   

Yes, we would. No matter what format you use, you'll have to look up the 
documentation. But if you're using a standard, well-known format, you 
*won't* have to spend time worrying about how escaping works or 
character encodings or line sizes or anything else. (And the Cabal 
people won't have to spend time designing all these details either.)

> Did I say Emacs?  Don't other editors/IDEs/etc. have the ability to
> syntax-highlight various files, generate code, etc.?
>
> And whatever editor you use to edit Haskell code with, whilst you
> could write Haskell code in Notepad, etc. isn't it easier using an
> editor with at least syntax highlighting?
>   

Unfortunately, I haven't found anything for Windows yet which has syntax 
hilighting for Haskell.

I use SciTE, which has hilighting for a bazillion languages (including 
XML and JSON), but not Haskell sadly.

>>> ... except this "home grown thing" _is_ a file format.
>>>
>>>       
>> Yeah. Just not a very nice one. And one that's supported by only one tool in
>> the entire world.
>>     
>
> Well, which other tools need to support it?
>   

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.

> 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.

> 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"...)