[Haskell-cafe] Re: Hoogle and Network.Socket

John Lato jwlato at gmail.com
Wed Feb 25 19:19:10 EST 2009

Achim Schneider wrote:
> John Lato <jwlato at gmail.com> wrote:
>> On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH
>> <allbery at ece.cmu.edu> wrote:
>> > On 2009 Feb 25, at 5:23, John Lato wrote:
>> >>
>> >> Brandon Allbery wrote:
>> >>>
>> >>> I have to second this; I'm a Unix sysadmin, 98% of the time if I'm
>> >>> writing a program it's for Unix *and* requires POSIX APIxs, and
>> >>> even if it could apply to Windows the program needed there would
>> >>> be very significantly different. __And we have a Windows group for
>> >>> that.
>> >>
>> >> 2. __As of now, the "Windows Group" seems to be mostly Duncan. __And
>> >
>> > Wrong Windows group: __Duncan doesn't work for us.
>> >
>> Sorry, I misunderstood you.  I thought you meant a Windows group
>> within the Haskell community, not within your company.
>> Honestly, what I wrote wasn't directed at you.  As I mentioned before,
>> writing code as a Unix sysadmin has very different priorities than
>> writing for many other problem domains.  Most of your code wouldn't
>> make sense outside a Unix context, whereas bytestrings, tries, or
>> graph libraries would.
> I don't think it makes sense to talk about missing support on any
> platform: In a strict sense, how well a platform is supported is a
> function of how many people care to use it. While there seems to be a
> disparity between people developing programs on/for Windoze and people
> working on Windoze's cross-platform capabilities wrt. Haskell, this
> does not mean that you can rightfully expect people who chose not to use
> your favourite platform to give a damn about it. Search for allies
> amidst your pals.

Somehow I really gave off the wrong impression.  Windows is most
definitely not my favorite platform.  My primary development computer
is currently a MacBook, and my secondary system runs Linux.  I'm
advocating for Windows for two reasons:

1.  There are a non-trivial number of Windows Haskellers, and they
frequently post about problems on this list.  I would like to make
their lives a little better..

2.  A substantial portion of computer users are on Windows.  If I want
them to use my software, or even expose them to the glory of Haskell,
I need to speak their language.

A possible third reason is that I have used some number of
gnu-toolchain-developed programs on Windows (using mingw), and the
experience is frequently miserable.  Graphics libraries lag, all sorts
of configuration errors, missing packages, etc.  Compared to that, the
GHC compiler chain and libraries are fantastic.  It pretty much works,
and I think it can be better.  I would like to see a wider adoption of
Haskell in general, and improving Haskell support for windows is would
definitely help.

> I honestly doubt that iff a viable[1] way to support multiple platforms
> exists any developer aware of it would choose a platform-locked in
> alternative. This is the only thing you can hope for, and the only
> thing you need to provide to other developers to get platform support
> for free. There's a free lunch, after all, but you gotta bring your own
> dishes. Or pay someone to spoon-feed you, but that's another issue.

I think Haskell is a lot closer to this than many other languages.
Generally, Haskell packages that don't work on Windows fall into one
of three categories:

1.  Packages that link to a C library, in which case it depends on the
underlying library.
2.  Packages that are closely tied to Unix/Posix.
3.  Packages that depend on one of the above (or another in this category).

It's the third category that's mostly under discussion here.  If
Package A is posix-dependent, but a cross-platform alternative is
available, then by using the cross-platform alternative Package B
really can get Windows compatibility for free (assuming equivalent
functionality between alternatives).  I really don't see anything
wrong with using Hoogle to increase awareness (although I would
appreciate it if platform-specific packages were searched as an


More information about the Haskell-Cafe mailing list