Announce: wxHaskell 0.2

Daan Leijen daanleijen at xs4all.nl
Tue Sep 16 23:18:03 EDT 2003


Hi Sven,

> 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):

wxHaskell consists of two layers: WXCore and WX.

The WXCore layer is supposed to be totally Haskell98 compatible
(or really easy to make compatible).

The WX layer is a nice haskellized version of the wxWindows
API on top of WXCore that uses extensions.

>   * 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 :-}

No, it is not. Actually on <http://www.cs.uu.nl/~daan/ddata.html> you
can
find a Hugs98 and "standard" haskell98 version. I just used this one as
I only
use GHC but it can easily be replaced.

>   * 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.

Thanks for the hint. I'll remove the type declaration.

>   * wx/src/Graphics/UI/WX/Attributes.hs uses existentially 
> quantified data constructors (:=, :~, ::=, and ::~) for purely 
> aesthetical reasons.

Yes, I am considering changing it to "=:" operators, that look less
nice,
but remove the dependency on rank-2 polymorphism. However, I haven't
removed them yet as 1) not enough people complained, 2) any serious
haskell 
compiler supports "forall" now, and 3) the (:=) operator looks *really*
good, 
and 4) I depend on more devious things already which are harder to
avoid, namely:

>   * Type synonyms in instance heads + complex instance heads are quite
pervasive:

This is a devious thing to do, but totally unavoidable given the way I
model
inheritance with phantom types. I have considered using type classes to
model
the inheritance but that leads to a) other dependencies on extensions,
b) hard
to understand error messages, and c) a much more complex model. (See
Andre Pang's
master thesis for a ingenious way to model full inheritance)

On the other hand, phantom type inheritance is easy *and* using type
synonyms
in instance heads is *very* convenient (a huge improvement compared to
all the
instance declarations I had to write for GIO). (So, I guess I am making
a case for
supporting this extension in future Haskells as it is so useful).

>   * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with 
> functional dependencies.

Hmm, yes, but these could be removed -- they are not very important.

> 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.

I share your concerns. However, keep in mind that WXCore is Haskell98 +
FFI,
and that only the nicified abstraction WX uses extensions. That is,
anyone can
build another nicified abstraction that is H98 compatible. However, it
seems that
for "real" libraries, one wants a bit more power.

In the end though, I would like wxHaskell to be an open community effort
and not to
be "daan's" library. In that sense, anyone can change the libraries
interface if
enough people support that. I am not emotionally attached to my design
and will certainly
support people that want to change or fix the library (especially given
my lack
of time to spend on this project :-). 


All the best, and thanks for your comments,
  Daan.

> Cheers,
>     S.
> 
> 
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org http://www.haskell.org/mailman/listinfo/haskell
> 
> 




More information about the Haskell mailing list