On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily.
My priorities for Gtk2Hs (the second most popular GUI toolkit in John Hughes's survey) are very similar. We have adopted wxHaskell's style of attributes which is what uses existential types. I should not that in both cases the use of existential types is not essential. It was done that way only because the symbol that people wnated to use ':=' happens to be a constructor operator. If '=:' were used instead then existential construcotr types would not be necessary. We might make use of MPC +FunDeps if they were standard but it is not at all crucial. Our main concern is namespace issues. As I've said before, Gtk2Hs is a very large library but with the current module system it must export a flat name space. wxHaskell solves this with somewhat of a hack. It defines many multi-parameter type classes to allow the same name to be used by different widgets (with hopefully the same general meaning). I think this would be better solved by using qualified names. We have been trying hard to avoid non-H98isms so that we can hope to work with compilers other than ghc. So having these features standardised would allow us to present a better api and allow us to remain portable.
What other tools "must" be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come?
Another gripe is in the FFI, in the handling of include files. The method preferred by GHC and the method preferred by the FFI spec are rather at odds. GHC prefers the file to be specified on the command line while the FFI spec prefers it to be specified in each and every FFI import declaration. If one does the latter then GHC refuses to inline foreign calls across modules. Other mundane but useful things include the ability to specify different FFI import decls for different platforms without using #ifdef's. This would allow a program using a Gtk2Hs GUI to be compiled to bytecode with YHC and run on different platforms, rather than having to be built differently on each platform. (The issue is that even for portable C libs, the calling convention and symbol names can differ across platforms. This is true to a minor degree with the Gtk+ library.) Duncan