[nhc-bugs] Cygwin and GHC

[Mike Thomas]

Hi Simon.

I hope my comments below can be taken constructively - it's midnight here.

The thrust is that I believe it to be folly to fake Posix support under
Windows, for reasons of efficiency, elegance and relevance of GHC to the
Windows world.

> The GHC core team is now down to Simon M and me.   Sigbjorn
> heroically helps out on Win32 stuff, but it isn't his job.  So we have
> strictly limited effort available.

Can you comment on how much longer the GHC core team will exist?

> I am therefore deeply reluctant to provide both GHC-for-mingw32
> and GHC-for-cygwin.   One build on Win32 is enough!   We ended
> up with a mingw32 basis because it meant we could make GHC
> completely self-contained -- no dependence on cygwin1.dll etc.
> This was *huge* step forward: GHC installs and runs with no problem
> on Windows now.
>
> Therefore I ask:
>
> can someone summarise succinctly what the
> problems with GHC-for-mingw32 are?
>
> The ones I know about are these:
>
> 1.  GHC does not understand cygwin paths in the file names passed
> to it on the command line.
>
> 2.  GHC on Win32 does not come with a Posix library.  If we used a
> Cygwin basis, Posix would be easy because cygwin does all the hard work.
>
> 3.  I/O on Win32 is *blocking*.   A blocking input operation freezes all
> the
> other Haskell threads.
>
> Are there any other problems?

>From my perspective as a Windows user and developer, the only problem is
that GHC (and many other programming languages) tries to support Posix as a
Very Important Part of the Language Library.  I think that attempting to
provide *substantial* Posix compatibility under Windows has the same ring as
the converse - Win32 API compatibility under Unix.

There will never be a seamless fit between the two methodologies.  The end
result is that, for example, Cygwin based software (also Nutcracker etc -
name your own Unix fudge on Windows) is always slower and clunkier and
harder (than an equivalent native application) both for the programmer who
tries to straddle two paradigms and for the end-user of the products the
programmer provides.

This can only reflect badly, in a Windows world on Haskell, in the eyes of
the same developer and end-user.  I speak from experience as a developer who
works during the day on a large mixed Unix/Windows petroleum industry
package.

> My own ill-informed thoughts on these are:
>
> 1.  GHC already fudges filenames to take account of the Win32/Unix
> conventions.  We could add more fudges, to change /cygwin/c/foo
> to c:\foo, for example.   Perhaps controlled by a -cygwin flag to tell
> GHC-for-win32 whether to use cygwin fudges or not.  Heuristic, yes;
> but might solve the problem for 99% of customers.

I believe that it is better to leave filename fudging to the shell than the
compiler tools, otherwise you make maintenance of your compiler much harder.
(I have previously mentioned MSYS in this context.)  I believe that this is
particularly true if you are going to continue using Mingw32 - a move I
support.

>
> 2.  Mingw32 provides quite a lot of Posix, so if someone was prepared
> to put in a bit of work we could get a good part of the Posix library
> available on Win32, still via mingw.  Any volunteers?

At risk of sounding churlish - not me I'm afraid as I think it pointless.
If I wanted to write Unix software I would run Linux at home.  Mingw32 per
se provides msvcrt.dll runtime native Windows compatibility.  Any Posix
compatibility it may have is entirely coincidental.

If you chose to implement Posix, it might be worthwhile looking at the OCaml
runtime which from memory has some stuff.  Also the Windows port of Tcsh.

Expanding the scope of the Win32 library might be more fruitful though.

> 3.  Non-blocking I/O is a soluble problem: Win32 provides suitable
> primitives.  But they are different to the Unix primitives, so there is
> work to do in the runtime system to make it work.  This is harder
> for a volunteer to do because it's in the runtime system, but not
> impossible.
>
>
> Any thoughts?  Ideas are much more likely to be implemented if
> they are either easy, or you can help do the job!

I may be able to help with small things, but I am heavily involved in other
projects at the moment (Grass, Gnu Common Lisp and my own stuff).

Kindest regards, I'm going to sleep

Mike Thomas