Re: Current state of GUI libraries for Haskell
Thank you to everyone who answered to my question Claus Reinke wrote: > PS: Please do contribute to Olaf's GUI survey. If he could complete > the GUI information on his Haskell page, that would be very useful. > I share the suspicion that, after the FP community has invented all > those nice new approaches to functional GUIs, many of them are no > longer supported, let alone portable. I would like to have an > overview of the current state of the art (please include old > libraries, too - just because they are no longer supported, that > doesn't mean they are not useful any more). Taking up Claus' suggestion I enumerated all the systems I now know about on my Haskell page: http://www-i2.informatik.rwth-aachen.de/Forschung/FP/Haskell/#guis Simon Peyton-Jones wrote: > I don't think any of these apart from Fudgets is currently released, stable, > and actively maintained; nor, even if they > were, do their authors believe that they are the last word (but they should > speak for themselves). Well, the overview shows that a lot has been done on GUIs for Haskell. However, selecting a reliable and actively maintained system is still a problem. I'm surprised that Sigbjorn Finne was the only author of a GUI system who responded to my question. > The situation is far from satisfactory. Plenty of > space for people to make their mark. A big part of the problem is that > it's a *lot* of work to implement such a system. That's why we don't do it ourself ;-) Olaf -- OLAF CHITIL, Lehrstuhl fuer Informatik II, RWTH Aachen, 52056 Aachen, Germany Tel: (+49/0)241/80-21212; Fax: (+49/0)241/-217 URL: http://www-i2.informatik.rwth-aachen.de/~chitil/
RE: Current state of GUI libraries for Haskell
> We have developed here a large Haskell program with ghc-2.08. > Now we want to > extend it by a graphical user interface, preferably using > Haskell as well. I am > aware of Fudgets and Haggis, but it seems that their > development ceased in 1996 > (correct?). Obviously we are searching for a library which > will still be > supported for some time (we are currently moving to ghc-3.0x, > because we need > HDirect). I worked a bit with TKGofer and liked it. Also I > have more trust in > the future of an interface to TK than a library that is > developed from scratch. > > Are there other choices? Is there a TKHaskell (under > development)? Does anybody > have experiences with using one of these GUI libraries? > > I'm sure we are not the only ones interested in this subject. I'm sure you're not! (Though I don't think anyone else replied to your message, surprisingly.) Here's what I know about: - Chris Dornan is developing a Tk/Haskell. I don't think he's publicly released a version yet, though. - Sigbjorn Finne plans to release a version of Haggis that works with the latest GHC, in the next month or two. - Meruig Sage is working on sort of combination of Haggis, Fran, and Clock. - Enno Scholz has a working Pidgets system. - Einar Karlsson made a sort of Tk/Haskell system for his programming environment work. - Magnus Carlsson and Thomas Hallgren's Fudgets is still alive and kicking. I don't think any of these apart from Fudgets is currently released, stable, and actively maintained; nor, even if they were, do their authors believe that they are the last word (but they should speak for themselves). The situation is far from satisfactory. Plenty of space for people to make their mark. A big part of the problem is that it's a *lot* of work to implement such a system. Simon
Re: Current state of GUI libraries for Haskell
Timothy Robin BARBOUR writes: > The last I read about Haggis was that it would be ported to ghc-2.xx > and be involved in the ghc / hugs integration. > Modulo a couple of Makefile tweaks, Haggis is just about ready to be added to the Glasgow fptools CVS repository, which is publically accessible for people that want to have a look/contribute. This version should compile with the latest&greatest version of GHC. Re: "official" GUI system of the project that includes combining Hugs and GHC together - this is still up in the air, we're looking at a bunch of different ways of doing this. Related to Haggis, one option is to use the basic Haggis programming model (i.e., Concurrent Haskell + virtual I/O devices) and layer it on top of a Tk binding (on top of TkHaskell, probably) or some other set of widgets/controls. Adopting Haggis in its full glory(?) won't happen, it would just be too much work to get something slick, maintainable and portable across platforms by doing it all ourselves in Haskell. Another option is not to write the GUI in Haskell at all, but use VB, JS or Java instead, plugging in your Haskell code by wrapping it up as a CORBA or COM object. This approach has its merits if you'd like to convince non-Haskell programmers to use Haskell as part of their projects. --Sigbjorn
Re: Current state of GUI libraries for Haskell
The last I read about Haggis was that it would be ported to ghc-2.xx and be involved in the ghc / hugs integration. Is this port still in progress or was it abandoned ? Personally I had been happily anticipating the completion of the port, since I used Haggis in the past and was rather impressed. I have not been writing GUIs lately, but the need is bound to arise eventually, and I always thought Haggis would be available for this purpose. I do not want to use Fudgets or TkGofer etc - I want to use Haggis! Tim -- -- T.R.BARBOUR Email : [EMAIL PROTECTED] -- Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia --
Re: Current state of GUI libraries for Haskell
> > Of course, access to the Java libraries is also one of the objectives of > > those who have started to base their Haskell implementations on Java or > > on the JVM. > > Do you have a URL for this project? I asked alastair about doing this and > he said there are in-principle problems with getting this to work > efficiently. Specifically: 1) As of 1 year ago, all Java implementations seemed to have very slow memory allocation - at least 10 times slower than HBC/GHC/SML-NJ. 2) Each object format requires a new class file. Class files are large. 3) (The real killer:) The JVM doesn't support tail recursion and the Java folks say it never will (because their security stuff exploits this fact.) > Alternatively, fudgets could sit on top of AWT As Satnam Singh and I did with Budgets (see link on my home page). -- Alastair Reid Yale Haskell Project Hacker [EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
Re: Current state of GUI libraries for Haskell
Alex wrote: >Another approach, which would perhaps be more generically useful is to >use Java via the Java Native Interface. I agree. At least it is worth a try, and I this is what I'm currently working on (anyone else out there on the same project?-). There are quite a few problems, though: - JNI is part of this little discussion between SUN and MS (not too bad in principle, there are still several products which support JNI on various platforms - including Windows; nevertheless, it hampers progress and acceptance of the interface, not to mention the other native interfaces on the market) Corollary: despite all marketing hype, the future of Java hasn't been decided yet - JNI is on the move. Only the reference document is up to date (if you collect all the pieces together), and it is not exactly verbose. - JNI is always in beta, and debugging is no fun if you have to juggle with three languages and two experimental dynamic interfaces. - ... My current approach is to connect Haskell/Hugs and Java/JDK using GreenCard 2 and JNI. I thought this first step would be simple, but progress has been almost discouragingly slow. Of course, access to the Java libraries is also one of the objectives of those who have started to base their Haskell implementations on Java or on the JVM. >By allowing Haskell to script and control Java objects, Haskell would >instantly have: One of the slides of a JNI talk at JavaOne said explicitly: don't try to write Java programs in C using JNI There are various reasons for this. My hope is more to enable a connection between larger chunks of software (components) written in Java and Haskell. Industry uses Java to write their GUI and Haskell to write the `real' program. >1. a reasonable gui (AWT and Swing) >2. a decent set of network and http libraries >3. decent database libraries (ODBC/JDBC) >4. RPC and Corba support via Java RMI >5. encryption >6. Linda style parallel processing via javaspaces >7. a better relationship with the rest of the industry > >And it would offer these capabilities on a cross platform basis. >Developers could wrap the Java libs with more sophisticated Haskell >interfaces as the language evolves... More problems on this way. In essence, access to Java libraries is pretty much Java-specific, and apart from the complex interlanguage connection, we all know how good Haskell's current type system can cope with object-oriented programming styles. I don't know whether the GUI is reasonable (still being adjusted to custumer needs), but I agree with 7, which makes the GUI interesting (even our best FP GUIs are simply unknown outside the FP community). Nearly all of the other points should be taken with a good grain of salt: having a feature on the Java side does not at all mean that you just need a JNI-connection to import it all into Haskell (and we don't really want to write too much Java-code in the Haskell IO monad, do we?). Enough bad news for today (back to those segmentation faults in JNI_something). Unless someone else has it all ready now, I will continue to work on the Hugs/GreenCard/JNI/Java road over the next weeks, and if I don't jump out of the window because of the persistent, not well documented obstacles, then we should have some basis for further experiments before this year is over (N.B: [a] no promises here! [b] once I get the basic connection to work, there is still a lot of work to be done!). If everything should work out well, the connection to JNI could be useable by all systems that support GreenCard.. Claus PS: Please do contribute to Olaf's GUI survey. If he could complete the GUI information on his Haskell page, that would be very useful. I share the suspicion that, after the FP community has invented all those nice new approaches to functional GUIs, many of them are no longer supported, let alone portable. I would like to have an overview of the current state of the art (please include old libraries, too - just because they are no longer supported, that doesn't mean they are not useful any more).
Re: Current state of GUI libraries for Haskell
On Thu, 6 Aug 1998, Claus Reinke wrote: > >Another approach, which would perhaps be more generically useful is to > >use Java via the Java Native Interface. > > My current approach is to connect Haskell/Hugs and Java/JDK using > GreenCard 2 and JNI. I thought this first step would be simple, but > progress has been almost discouragingly slow. Another possible approach which would sidestep the sun JNI issue, would be to use the Kaffe source (www.transvirtual.com). I took a look and the source *seems* clean though I haven't tried anything with it. Once JNI stabilizes, you can make the architecture more generic. > Of course, access to the Java libraries is also one of the objectives of > those who have started to base their Haskell implementations on Java or > on the JVM. Do you have a URL for this project? I asked alastair about doing this and he said there are in-principle problems with getting this to work efficiently. > >By allowing Haskell to script and control Java objects, Haskell would > >instantly have: > > One of the slides of a JNI talk at JavaOne said explicitly: > > don't try to write Java programs in C using JNI > > There are various reasons for this. Can you explain more here? > My hope is more to enable a > connection between larger chunks of software (components) written in > Java and Haskell. Industry uses Java to write their GUI and > Haskell to write the `real' program. Alternatively, fudgets could sit on top of AWT (The chalmers ftp server is down so I can't read the fudgets paper) > >1. a reasonable gui (AWT and Swing) > >2. a decent set of network and http libraries [...] > >7. a better relationship with the rest of the industry > > > >And it would offer these capabilities on a cross platform basis. > >Developers could wrap the Java libs with more sophisticated Haskell > >interfaces as the language evolves... > > More problems on this way. In essence, access to Java libraries is > pretty much Java-specific, and apart from the complex interlanguage > connection, we all know how good Haskell's current type system can cope > with object-oriented programming styles. I don't think this is sufficiently true to reject a java interface (I am guessing that you don't either). For example, one might write an interface that imports java headers as haskell modules so that you could do... > main = do > vec <- Java_lang_Vector.new_a3 -- create new vector > -- new is implicitly static > vec # Vector.addElement_c1 12 -- add element to vector > --print size of vec > putStr $ show $ vec # Java_lang_Vector.size_21 This would be annoying in that you would 1. have to append the hash of the signature to each method name 2. reference the class name every time you want to call a function 3. use package names in referring to the class However then the primary task of a Haskell library writer it the mapping of Java functionality into a more reasonable Haskell namespace -- as opposed to implementation of this functionality itself. Once Haskell 2.0 adds, as Simon says, "Allow ad-hoc overloading as well as type classes (a la Java or C++)." then everything becomes much more straightforward. I would also add as a todo item for Haskell 2.0, fix the module namespace. (I know that this use of (#) is outdated, but I don't know the current one. If there isn't any right now, how about (./)?) > I don't know whether the GUI is reasonable (still being adjusted to > custumer needs), Fair enough, but it is probably advancing much faster than Tk and > but I agree with 7, > which makes the GUI interesting (even our best FP GUIs are simply > unknown outside the FP community). Nearly all of the other points should > be taken with a good grain of salt: having a feature on the Java side > does not at all mean that you just need a JNI-connection to import it > all into Haskell (and we don't really want to write too much Java-code > in the Haskell IO monad, do we?). Library writing is substantially easier if it consists mainly of namespace mapping rather than actual implementation of new libraries (e.g. encryption or guis or database connectivity). Calls to Java that really are stateless can of course get implemented by Java calls inside an unsafeperformIO block... The point I am making here is not that we want to use the java libs directly. My point is that the ability to use the java implementations allows the FP community to focus on better representations and DSELs that are richer than the OO noun.verb() or noun.getProp() syntax. > Enough bad news for today (back to those segmentation faults in > JNI_something). Unless someone else has it all ready now, I will > continue to work on the Hugs/GreenCard/JNI/Java road over the next > weeks As I said above, you might want to check out Kaffe because you have access to source and two different native interface specs. -Alex- _
Re: Current state of GUI libraries for Haskell
Another approach, which would perhaps be more generically useful is to use Java via the Java Native Interface. From the javasoft page: "Java Native Interface is a standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications. The primary goal is binary compatibility of native method libraries across all Java virtual machine implementations on a given platform." (http://www.javasoft.com/products/jdk/1.2/docs/guide/jni/index.html) By allowing Haskell to script and control Java objects, Haskell would instantly have: 1. a reasonable gui (AWT and Swing) 2. a decent set of network and http libraries 3. decent database libraries (ODBC/JDBC) 4. RPC and Corba support via Java RMI 5. encryption 6. Linda style parallel processing via javaspaces 7. a better relationship with the rest of the industry And it would offer these capabilities on a cross platform basis. Developers could wrap the Java libs with more sophisticated Haskell interfaces as the language evolves... -Alex- ___ S. Alexander Jacobson i2x Media 1-212-697-0184 voice1-212-697-1427 fax On Wed, 5 Aug 1998, Olaf Chitil wrote: > We have developed here a large Haskell program with ghc-2.08. Now we want to > extend it by a graphical user interface, preferably using Haskell as well. I am > aware of Fudgets and Haggis, but it seems that their development ceased in 1996 > (correct?). Obviously we are searching for a library which will still be > supported for some time (we are currently moving to ghc-3.0x, because we need > HDirect). I worked a bit with TKGofer and liked it. Also I have more trust in > the future of an interface to TK than a library that is developed from scratch. > > Are there other choices? Is there a TKHaskell (under development)? Does anybody > have experiences with using one of these GUI libraries? > > I'm sure we are not the only ones interested in this subject. > > > Thank you for any comments, > Olaf > > -- > OLAF CHITIL, Lehrstuhl fuer Informatik II, RWTH Aachen, 52056 Aachen, Germany > Tel: (+49/0)241/80-21212; Fax: (+49/0)241/-217 > URL: http://www-i2.informatik.rwth-aachen.de/~chitil/ >
