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.

* Type synonyms in instance heads + complex instance heads are quite

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: 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Hi Vincenco

...

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)

Can you provide a link? I can't find it. Does he still use phantom types? Also, I am sure I have read something posted by you wich explained how to model single inheritance with phantom types, can you provide me some reference?

Andre Pang is a master student of Manuel Chakravarty. He made a binding to Cocoa/Objective C using template Haskell. I have just talked with him, maybe you can find his thesis using the above information. (or maybe one of them reacts to this email :-) I have described the inheritance trick in, hmm, I think in "calling hell from heaven and heaven from hell" http://www.cs.uu.nl/~daan/pubs.html I am currently working on functional pearl though that describes everything you can do with phantom types (like relational expressions) from scratch.

Do you model multiple inheritance someway?

No :-) It is possible though but makes things more complex.

Does wxwin use multiple inheritance?

Just two (non-essential) classes use this, so I could get away with just modeling single inheritance. Cheers, Daan.

Bye

Vincenzo

_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui

Alle 22:18, martedì 16 settembre 2003, Daan Leijen ha scritto:

Yes, I am considering changing it to "=:" operators, that look less nice

other possibilities are #= , ^= , %= , <== Yes, I am trying to get that "not enough" to "enough" ;) Bye V.

[ Removed Haskell list from Cc:, it's becoming a bit wxHaskell specific... ] Daan Leijen wrote:

...

* You need `-package parsec' for linking wxdirect nowadays.

Thanks for the hints. I'll look into it for a future version. I will not actively support CVS GHC's though -- that will be too much work :-)

Well, if you like it or not: You'll have to handle versionitis somehow. The upcoming GHC 6.2 will need that flag, too.

...

* When HelloWorld terminates, it segfaults in wxVariant()'s destructor. [...] I am quite sure that this has nothing to do with C vs. C++ :-) (I am not linking at all with C++ directly -- instead I am using extern C wrappers that are used in a separate dynamic link library with their own C++ runtime system. This is just like calling any other systems library.)

No, it is not: A library has no "runtime system", it's usually the startup code which cares for things like global constructors/destructors, sets up exception handling, initializes the memory allocator, etc. And you get the correct startup code for the language you are using (C vs. C++) "under the hood" when linking your application together. At least that's the story for *nix systems I'm aware of, I don't have a clue on WinDoze. One of the problems with wxHaskell currently is that the applications are linked together (via GHC) with a C compiler, not a C++ one.

The segfault is really weird though -- it might be that you started "main" twice from GHCi (a known bug in wxGTK),

Nope, I used GHC and started the resulting executable directly.

that your GHC is broken,

The usual "help desk" answer... ;-)

that you use an old GTK,

I'm on the bleeding edge already, doing regular online updates of my SuSE system.

anything really.... :-(

Another suspect is casting: I'm not quite sure what you are doing in the low-level parts, but I see a lot of casts. The problem is: In C++, casting is not necessarily value preserving for pointers in the presence of multiple inheritance (or virtual base classes, IIRC).

...

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

I am fairly hesitant here -- this means that I need two different package description files -- one for binary installs and one for developer installs. I'll look into it, but since I am not a real unix wizard, maybe you can tell me offline what you exactly need/want.

I was thinking of something like an -rpath option for the linker, so that the resulting executable would automatically find the dynamic library. BTW, do we really need a *dynamic* library here? Cheers, S.

Let me provide a few comments about the C++ linking story.... Sven Panne wrote:

No, it is not: A library has no "runtime system", it's usually the startup code [...]. And you get the correct startup code for the language you are using (C vs. C++) "under the hood" when linking your application together.

On Mac OS X, Windows/Mingw32 and RedHat Linux 8, you get the same startup code no matter whether you use gcc or g++. The only difference between the gcc and g++ linker drivers is that g++ adds -lstdc++. On Mac OS X, every dynamic library gets it's own startup code (haven't checked on Linux or Windows, but I guess it's the same). Daan Leijen:

Yes! otherwise we *do* get all those C vs. C++ linking problems that you describe. Actually, on most platforms you can't even link in C++ code due to all kinds of linking errors with the standard C libraries (stdc vs. stdc++)

Maybe GHC can be convinced to use the C++ compiler to compile all its stuff?? That would surely solve our problems.

A small mixed C++ & Haskell test program, runs fine on Mac OS X, Windows and RedHat 8 when I add -lstdc++ to the command line. On Windows, there's of course the problem that GHC includes it's own copy of GCC, but no C++ includes, but I happen to have another copy of them :-). While being short, my test program uses static constructors and destructors, and it calls the C++ standard library (iostream and string, to be exact), and everything works perfectly. What kinds of problems did you experience? GHCi, on the other hand, cannot currenlty load C++ object files (nor can it currently load the C++ standard library on systems where it's a static library), so using dynamic libraries is definitely necessary at least during development. Of course, it would be nice if I could just statically link my wxHaskell application when I'm done, but GHCi is more important. Cheers, Wolfgang

Jens Petersen wrote:

http://haskell.org/~petersen/rpms/wxhaskell/

(current public_html seems to be disabled on haskell.org).

Not so; you have a syntax error in your .htaccess (perhaps apache was upgraded and the syntax changed?). If you remove it or correct the error, your page will be served. --KW 8-)

On Fri, Sep 19, 2003 at 11:15:39AM +0200, Daan Leijen wrote:

...

Thanks for the release. 0.2 seems to build much better on Linux. :) I built an rpm package with ghc-6.0.1 for wxGTK2 and put it at

Thanks! I'll try it out and put it on sourceforge (if that is ok with you).

Sure.

I also like your naming scheme, I guess I should also include the ghc version and processor in the name of binary releases.

Good, thanks. :)

(btw. what does the extra "-2" mean in the version? (like wxhaskell-ghc6.0.1-0.2-2.i386.rpm)

That is a packaging thing, the release number, which is to be incremented each time some change is made to how the package is built. Jens