collecting requirements for FDs

[Claus Reinke]

> What other libraries should Haskell' support, and what are their
> requirements?

useful initiative! will your collection be available anywhere?

may I suggest that you (a) ask on the main Haskell and library lists
for better coverage (I would have thought that the alternative Num
prelude suggestions might have some use cases), and (b) collect 
non-use cases as well (eg, where current implementations are 
buggy/incomplete/do different things, or where other reasons have 
prevented Haskellers from using FDs so far)? I think trying to clean
up the latter will be more effective than wading through dozens of
variations of the same working examples - you're looking for 
counter-examples to the current design, aren't you?

and just in case you haven't got these on your list already, here are 
some examples from earlier discussions on this mailing list:

- ticket #92 has module Data.Records attached to it.
    http://hackage.haskell.org/trac/haskell-prime/ticket/92
    I'd like to be able to use that in Haskell'. the library is useful in 
    itself (I've used its record selection and concatenation parts when 
    encoding attribute grammars), and I also suggested it as a good 
    testcase for Haskell' providing a sufficient (but cleaned-up) subset 
    of currently available features. but it is also an example of code that

    - works with GHC, but not with Hugs; one of those problems 
        I reported on hugs-bugs:
        http://www.haskell.org//pipermail/hugs-bugs/2006-February/001560.html

        and went through a few of the Hugs/GHC differences here 
        on this mailing list:
        http://www.haskell.org//pipermail/haskell-prime/2006-February/000577.html
    
        and used the Select example to motivate the need for relaxed
        coverage in termination checking:
        http://www.haskell.org//pipermail/haskell-prime/2006-February/000825.html        

        I have since come to doubt that GHC really solves the issue,    
        it just happens that its strategy of delaying problems until they may
        no longer matter works for this example; but one can construct other 
        examples that expose the problem in spite of this delayed complaining 
        trick. see my own attempts to show FD problems here:
        http://www.haskell.org//pipermail/haskell-prime/2006-February/000781.html

        or Oleg's recent example on haskell-cafe:
        http://www.haskell.org//pipermail/haskell-cafe/2006-April/015372.html
    
        while I didn't quite agree with his interpretation (see my answer
        to his message), he did manage to construct an example in which
        GHC accepts a type/program in violation of an FD.

    - requires complex workarounds, thanks to current restrictions,
        where the same could be expressed simply and directly without;
        (compare the code for Remove in Data.Record.hs: the one in 
         comments vs the one I had to use to make GHC happy)

- things like a simple type equality predicate at the type class level
    run into problems with both GHC and Hugs. reported to both
    GHC and Hugs bugs lists as:
    http://www.haskell.org//pipermail/hugs-bugs/2006-February/001564.html

- the FD-visibility limitations strike not only at the instance level. 
    here is a simplified example of a problem I ran into when trying 
    to encode ATS in FDs (a variable in a superclass constraint that
    doesn't occur in the class head, but is determined by an FD on
    the superclass constraint):
    http://hackage.haskell.org/trac/ghc/ticket/714

- the HList library and associated paper also use and investigate
    the peculiarities of FDs, and variations on the TypeEq theme
    (it has both unpractical/portable and practical versions that 
     make essential use of some limitations in GHC's type class
     implementation to work around other of its limitations; it
     demonstrates wonderfully why the current story needs to
     be cleaned up!):
    http://homepages.cwi.nl/~ralf/HList/

hope that's the kind of thing you are looking for?-)

cheers,
claus