I just had a look at wxHaskell (GHC from CVS, about a week old, SuSE Linux 8.2 on x86). A few remarks: * It would be nice if the directory created by unzipping wxhaskell-src-0.2.zip contained a version number. * It would be even nicer if wxhaskell-doc-0.2.zip unzipped into a *single* directory. * You need `-package parsec' for linking wxdirect nowadays. * When HelloWorld terminates, it segfaults in wxVariant()'s destructor. I have no idea what's going on here, but I can only repeat my warnings stated some time ago: Mixing a C++ library with pure C (= GHC's code) is a highly delicate, platform/compiler dependent and fragile thing to do... * The package configuration should include linker flags for the path of libwxc.so, otherwise a non-superuser has to fiddle around with LD_LIBRARY_PATH and the like. Furthermore, the library documentation says: "Portability: portable", but this is not the case at all, wxHaskell uses quite a few extensions (apart from the FFI, which can be considered portable nowadays): * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around with unboxed values and GHC interna for performance reasons. Is this really necessary? (Apart from that, it triggers a bug in GHC's new Lexer :-} * The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses a scoped type variable. This could probably be rewritten to something more portable. * wx/src/Graphics/UI/WX/Attributes.hs uses existentially quantified data constructors (:=, :~, ::=, and ::~) for purely aesthetical reasons. * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with functional dependencies. * Type synonyms in instance heads + complex instance heads are quite pervasive: wx/src/Graphics/UI/WX/{Events,Window,Frame,Menu,Timer,Draw,Controls,Dialogs}.hs wxcore/src/Graphics/UI/WXCore/Layout.hs I don't want to sound too negative, Daan has done an impressive job, but I'm a bit concerned about all this non-portable stuff when we are planning to use wxHaskell as the basis for our GUI efforts. Cheers, S.