[darcs-devel] Moving system code to Haskell

[David Roundy]

On Sat, Aug 27, 2005 at 10:51:12PM +0100, Ian Lynagh wrote:
> On Fri, Aug 26, 2005 at 06:14:32PM +0200, Juliusz Chroboczek wrote:
> > By moving this code to Haskell, we're becoming dependent on the
> > atomicity behaviour of Haskell library calls, which is undocumented and
> > might change between releases.  Thus, it is quite likely that the
> > change breaks Darcs over NFS, at least in some versions of Ghc.
> >
> > An additional concern is that the people who can do correct atomicity
> > over exotic file systems are most likely C programmers.  By moving this
> > code to Haskell, we make it impossible to people like the NFSv4, LUFS
> > or FUSE developers to check our code over their filesystems.
> > 
> > Ian, I would like to strongly encourage you to revert these changes.
> 
> Can you point out specific places where this will cause problems please?
> I'd really like to rid darcs of C code completely, so you'll probably
> have to show me concrete examples which we can't do in Haskell for some
> reason to convince me to go the other way!

Ian, I'm also not entirely comfortable with moving this code into Haskell,
although I don't feel strongly on the issue.  Juliusz is right that the
folks who are likely to be most capable of contributing or reviewing this
sort of code are far more likely to be C programmers than Haskell
programmers (e.g. Juliusz himself).

I know *I* don't have the experience to write careful_atomic_create myself,
and if I did have to write it myself, I'd rather go out and search for good
example code in C and use that code directly than try to both learn how to
correctly take a lock atomically over insane filesystems and simultaneously
translate into Haskell.

And I'd *far* rather trust Juliusz to handle this side of darcs than risk
alienatin him by making it hard for him to read and modify his own code...
On the other hand, the haskell code looks like it's got somewhat fewer
opportunities for overflowish errors, which is definitely a plus (looking
in particular at the snprintf, and remembering that at one time we had an
snprintf that was overflowing its null character).

> While it may not be explicitly written down everywhere, I think we can
> assume that we will get the same atomicity guarantees as we would in C.
> Ultimately GHC is just going to be calling those same C functions anyway,
> unless there is good reason not to.

I would agree that the System.Posix library can be safely assumed to simply
call corresponding POSIX routines where there is a one-to-one
correspondence between System.Posix routines and POSIX routines (which is
pretty much all of them).

(In other words, I'm pretty much flip-flopping on the question...)
-- 
David Roundy
http://www.darcs.net