...

c:/cygwin/tmp/nhc...

That'll work, or just create a toplevel /tmp -- I always seem to end up doing so.

Haven't had to fiddle with the cygwin-mounts for a while now, and I like the idea of keeping in-cygwin software restricted to the c:/cygwin/tmp & co (instead of separate c:/tmp et.al.).

So, provided nhc98 can avoid depending on 'posix', don't just give up on using GHC for compiling nhc98 under win32 just yet.

Only postponed (pending no-posix version of nhc), not burried. (meanwhile, the nhc-build with gcc is making progress) Would that eliminate the reason for your ghc/cygwin binary? Intuitively, I dislike the idea of GHC giving up the chance of posix compatibility, if others (cygwin) have already put so much work into making it possible. nhc is probably not the only piece of Haskell that would like to use posix. Why would the posix package have made it into the hslibs otherwise? Perhaps those would be questions for the Haskell list: - who uses the posix package for what purposes? - who is affected by the current lack of posix support, now? - which uses of posix are envisioned that could be better served by Haskell-specific abstraction layers that may be easier to port than posix itself? Cheers, Claus