[Haskell-cafe] Re: Hackage on Linux
andrewcoppin at btinternet.com
Fri Aug 27 07:40:04 EDT 2010
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,
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...
> 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.
> 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
For example, in MathML, "2+2" becomes
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
<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?
"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:
> (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.
> 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"...)
More information about the Haskell-Cafe