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 > [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell > > _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell