[darcs-devel] Moving system code to Haskell

[John Meacham]

On Sat, Aug 27, 2005 at 07:41:00PM -0400, David Roundy wrote:
> > 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.

There seems to be an implicit assumption that there is little overlap
between the haskell and C crowds. I don't think that is true, in fact I
would consider both to be my native languages (with english perhaps
being 3rd..). 

Incidentally, I implemented a lock-free transational database providing
full ACID semantics (thats more than postgresql or mysql promise) that only
depends on the atomic operations as provided by NFS (which are less than
the guarenteed unix semantics) that some might find interesting. I am
not sure how much lock contention is an issue with darcs, but the
algorithm could probably be adapted. full support for provably correct
transactions and guarenteed knowledge of whether a change succeeded or
failed is a very nice quality. another nice quality is that you have
guarenteed progress. as in any client crashing at any point can't harm
or leave the db in a state where it can't accept new changes. 

http://repetae.net/john/computer/vsdb

in any case. if you are worried about the haskell implementations of
certain functions not providing unix semantics, you could always just
import the system calls directly. it would still be 100% haskell + FFI
(no c code to write), but would require a little marshalling to call the
native calls directly. 

as in

foreign import unsafe ccall "unlink" unlink :: Ptr CChar -> IO CInt

and now you can call the libc unlink directly from haskell. 

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈