[darcs-users] GHC package for darcs

David Roundy droundy at abridgegame.org
Mon Sep 20 11:26:30 UTC 2004


On Fri, Sep 17, 2004 at 10:56:30AM -0500, Taral wrote:
> On Fri, Sep 17, 2004 at 10:11:27AM -0400, Craig M. Lennox wrote:
> > However, when I read through the WishList on wiki, it makes me think
> > that a lot of these things (like the patch browser) would become
> > trivially easy if there existed a package interface that even a
> > fledgling Haskell programmer could call upon without having to reckon
> > with the complex underlying machinery of Darcs.

Yeah, adding an interface to darcs would be very nice.  There would be a
couple of ways to do it.  One would simply be to export all the modules
that darcs uses internally.  This wouldn't simplify anything, but would be
relatively easy (you'd just have to figure out how to create a ghc
package).

The other (better) idea would be to create a stable, simplified interface.
The trouble is that this is hard.  Until we've seen a few applications
using the interface, it's hard to know what will be too simple, and what
sorts of things need to be supported.

Another (perhaps even better?) idea would be to create a C interface to the
darcs internals.  This would obviously require a stable, simplified
interface, and would have the advantage allowing interfaces with all sorts
of interesting programs.

Perhaps more than one interface would be desired.  One might want, for
example, to create an interface that doesn't allow anything lower-level
than what can be done with darcs from the command-line, but that would
allow one to do it from another program.  Or one might want to be able to
do sophisticated patch manipulation, for example to implement a program for
tracking down bugs.  So many possibilities, it's hard to know where to
start, until there's someone who wants to actually use such an interface.
A classic chicken and egg problem.

> Actually, the underlying machinery is pretty simple. I added the
> following:
> 
> {
> hunk ./GNUmakefile 155
> +ghci: $(DARCS_OBJS) $(C_OBJS)
> +       ghci $(filter-out -Wall,$(GHCFLAGS)) $(OPTLLDFLAGS) darcs.lhs
> $(C_OBJS)
> +.PHONY: ghci
> +
> }
> 
> Then run 'make ghci' and have fun testing out various expressions.

This is a cool idea! If you send this patch, I'll accept it.

> My biggest problem when trying to understand darcs was the fact that the
> test code is *completely* intertwined with the function code. It makes
> things extremely hard to understand.
> 
> If I had the time, I would split Patch.lhs into:
> 
> Patch.lhs
> PatchIO.lhs
> PatchCommute.lhs
> PatchMerge.lhs
> Test/Patch*.lhs

This would be a good idea, except PatchCommute and PatchMerge should
definitely be in the same file, to make sure the compiler can do smart
optimizations.

And there should be a PatchData.lhs that is only imported by Patch*.lhs,
since the structure of a Patch should never be accessed by outside
modules.

I tried breaking up Patch.lhs once, but got a factor of two or so
slowdown.  I'm sure that with appropriate INLINE directives, it could be
done all right, but at the time I just gave up.
-- 
David Roundy
http://www.abridgegame.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20040920/577e1034/attachment.pgp 


More information about the darcs-users mailing list