Re: [Haskell-cafe] Re: Hackage on Linux

Ivan Lazar Miljenovic wrote:

On 27 August 2010 20:13, Andrew Coppin 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.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.

...

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