unix package

[Duncan Coutts]

On Thu, 2007-06-28 at 09:25 -0700, Bryan O'Sullivan wrote:
> Bayley, Alistair wrote:
> 
> > The unix package isn't available to Windows users. Unsurprising, maybe.
> > But, given that it seems to be a layer over the Posix API, would it be
> > reasonable to request that the unix package is made available on
> > Windows?
> 
> I've been thinking about just this, too.
> 
> The underlying problem is that Haskell's portable I/O-related libraries 
> are underpowered, particularly the stuff in System.Directory.  Try doing 
> any significant filesystem-related work using only the portable APIs and 
> you'll see what I mean.

Yes. I've got a little Gtk2Hs demo that shows you a directory tree with
file names and file sizes. With the portable Haskell directory stuff I
can't even get the file size, I'd have to open every file and use
hFileSize.

> A portable library that put a POSIX-like wrapper atop filesystem 
> operations would be a big win, particularly if it were distributed as a 
> standard library.  This is the approach that Python's standard libraries 
> take, and it works well.

Yes, we know that both POSIX and Win32 have operations to 'stat' a file
and get back some common attributes about it. Of course the intersection
of those attributes is not huge, but it at least contains the file size!

> If I had a vote on how Ian might spend his time, it would be on 
> something like this, which would have direct value to programmers by 
> addressing a significant deficit of the current standard libraries. 
> Splitting up the unix package seems more like an inconsequential 
> janitorial task.  Given finite resources, I'd prefer to tackle the task 
> with greater benefits.

Though it's also probably more work :-)

It seems to me, one of our main problems is that the current base
package cannot depend on the posix/unix or Win32 packages and so we
cannot easily implement the portable Haskell APIs on top of the existing
posix/win32 api bindings. All the portable stuff is currently
implemented on top of C wrappers which interally use cppery to call
posix or win32 functions. So fewer people feel able to contribute
because most of the code is not Haskell.

Perhaps with splitting the base package up we have the opportunity to
have the directory & IO stuff live in a package that can depend on
either the posix/unix or win32 packages, and implement the portable IO
stuff on top of those (probably still using cpp). 

Duncan