[wxhaskell-users] Re: Announce: wxHaskell 0.2

[Sven P. <Sve...@in...>]

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.