Priorities

[Duncan Coutts]

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