Win32 libraries for Haskell

Graham Klyne gk at ninebynine.org
Tue Feb 3 16:49:13 EST 2004


At 15:18 03/02/04 +0000, Alastair Reid wrote:
>(To be honest, I don't see the problem with having a Greencard 'dependency'.
>It's easy enough for public releases to include the machine-generated files
>and for those using cvs, they can fetch Greencard from cvs too.)

Part of the problem is knowing how much stuff one really needs to know about...

I just took a closer look at the GreenCard docs, and from a user/build 
perspective it looks easier than I feared.  I think the main concern for 
general libraries would be to stick to stable releases of GreenCard with 
ready-to-go binary distributions.  I agree that using GreenCard does not 
look like a major bind.

>Graham:
> > That might remove one learning-curve dependency... are there disadvantages
> > to doing this?
>
>Many people feel that machine generated output should not be put in cvs
>because:
>
>1) 'make', 'make clean', etc. don't do a rebuild using the
>    latest version of greencard.  This mostly affects the maintainer.
>2) Changes made to the generated files can be lost if the file is
>    regenerated.

Fair enough.

>Graham:
> > I also noted the lack of a test suite:  is there one for hslibs that might
> > be migrated?
>
>Sadly not.
>
>My approach to testing has always been to see if the HGL still works.
>This does some limited testing of the interactive operations.

HGL?

>There's no tests for things which touch disk, registry, etc.  It'd be easy
>(but tedious) to add this.

I'd be reasonably comfortable with a program which can be run using canned 
data and which gives a reasonable coverage of the functions.  In many 
cases, it might be possible to wrap this in an HUnit test framework.  My 
main concern would be if that created too many dependencies on other modules.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact



More information about the Libraries mailing list