[darcs-devel] Moving system code to Haskell

Juliusz Chroboczek Juliusz.Chroboczek at pps.jussieu.fr
Sun Aug 28 12:17:47 PDT 2005


>>     Sat Jul 30 16:17:03 CEST 2005  Ian Lynagh <igloo at earth.li>
>>       * Move atomic_create/sloppy_atomic_create to Compat
>> 
>>     Sat Jul 30 15:12:05 CEST 2005  Ian Lynagh <igloo at earth.li>
>>       * Move maybe_relink out of compat.c
>> 
>> I believe this to be a mistake.  A very dangerous mistake at that.

> Can you point out specific places where this will cause problems please?

1. The original code has been checked at least four times, by myself
and other people.  The first version of maybe_relink turned out to
have a subtle bug (that I've never been able to reproduce).  While I
trust that you've been careful in doing this translation, the new code
will need to be checked again.  Which is completely pointless work, as
the old code was fine.

2. This code is written in Haskell.  If somebody decides to make sure
that Darcs is safe over e.g. SMB, NFSv4 or some other non-POSIX
filesystem, it will need to be someone who is not only a specialist of
the filesystem in question, but can read Haskell.  Such people tend to
be difficult to find.

3. While there are strong guarantees about the atomicity behaviour of
system calls (Unix manual section 2), there are no such guarantees
about library functions (Unix manual section 3) or Haskell library
functions.  While I'm willing to take your word that createLink is
just a call to link(2), I'm curious to know whether you have actually
checked that this is indeed the case, and intend to keep checking at
every new release of GHC.

> 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.

Sorry, Ian.  ``I think we can assume'' is just not good enough.

> Ultimately GHC is just going to be calling those same C functions
> anyway,

Not necessarily.  Have a look at openFile in older versions of GHC.

> I'd really like to rid darcs of C code completely,

Why?  (You do have sound technical reasons for that change, right?)

> 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!

I'm sorry, Ian, but I think that the duty of justifying these changes
is on your side.

                                        Juliusz




More information about the darcs-devel mailing list