The future of Haskell discussion
There was a discussion at the Haskell workshop on the future of the language. It would be great to have some sort of minutes from this for those who were unable to attend. I gather that a standard GUI was mentioned; I'd particularly like to hear about what, if anything, was resolved about that. Thanks Simon
Here a short summary by Malcolm and me of the final discussion at the Haskell workshop: First Simon Peyton Jones stated that the Haskell'98 Report continues to be revised in small ways for correctness and readability. He will continue this until a whole month passes with no further changes, then issue a finalised new version (so send bug reports now). John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.) Rather than starting work on a successor to Haskell, people generally want to see `blessed addendums' to the Report, for common agreed extensions, e.g. FFI, exceptions, concurrency, MPTC, fundeps, etc. The FFI addendum is almost ready, but any others need volunteers, not to mention agreement between designers and implementations. The idea is that a solid reference definition/documentation of each extension should exist independent of any particular compiler (but there is a lack of volunteers). It was noted that the future job of designing Haskell-2 will be made much easier by many small steps rather than one large effort. My personal comment about application letters: I think your idea of a poster session with abstracts in the proceedings is very good. In fact, anybody already had the possiblity to give a 10 minute talk. But there was no special invitation to talk about applications and an abstract would certainly be useful for people not attending or future reference. Here a list of the 10 minute talks given at the workshop (Ralf, maybe you can put them on the workshop web page?): Simon Marlow: Haskell Libraries, The Next Generation Presentation of the hierarchical structure. Need more libraries and maintainers for them. Would like to have HaskellDoc and some standard testing method. Mark Shields: Lightweight Modules for Haskell Shortly stated that he is working on a new module system and would like every interested person to join. Wolfram Kahl: Animating Haskell by Term Graph Rewriting HOPS is a system for term graph rewriting that can also show the rewriting steps in a graphical animation. Similar to GHood but all intermediate redexes are shown. Translation of Haskell programs into HOPS by hand. Useful especially for understanding space leaks. Martin Sulzmann: TIE: A CHR-based Type Inference Engine He reformulates context simplification of Haskell classes in the constraint handling rule formalism. This gives a flexible framework for all kinds of extensions and variants of class systems. Manuel Chakravarty: A standard Foreign Function Interface for Haskell98 Basically finished (general part and C, not for Java). Solicits last comments from the general community. -- OLAF CHITIL, Dept. of Computer Science, University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767
Olaf Chitil <olaf@cs.york.ac.uk> summarised the 10 minute talks of this years Haskell workshop, including my presentation:
Wolfram Kahl: Animating Haskell by Term Graph Rewriting HOPS is a system for term graph rewriting that can also show the rewriting steps in a graphical animation. [...]
For clarification, a few core points: * I have a GHC extension, called MHA (for ``Munich Haskell Animator'') that automatically converts programs written in a subset of Haskell into HOPS modules. This is not yet publicly available, but this may change in the future. Contact me if interested. * Animation in HOPS can show every intermediate step, but it is also possible to show only a selection, currently by the module where the applied rules reside. On a 1.2GHz Athlon, I currently get up to over 1000 raw rule applications per second, and around 10 graph drawings per second, so striking some reasonable balance can be quite helpful. The current version of HOPS awaits mostly a thorough documentation update for release. The HOPS home page is: http://ist.unibw-muenchen.de/kahl/HOPS/ * Currently HOPS implements only one evaluation strategy, namely leftmost outermost graph rewriting with sharing preservation (without automatic sharing maximisation). With the standard rules in place, this corresponds to the original definition of lazy evaluation (also known as the ``D-rule''), which is different from the lazy pattern matching evaluation of sequential Haskell implementations. Naive translations can therefore yield inappropriate results, and for some Haskell programs this is still the case in the current version. Therefore, you have to understand the translation in order to be sure that what you see corresponds to what happens in the Haskell implementation. I hope to release MHA only after I have addressed this issue better than in the current version. * For a variety of reasons, I would tend to say that the HOPS/MHA approach is really not very similar to GHood. Some of them may already be apparent from the above, others would go into more detail then I intend to do in this message. Best regards, Wolfram
It seems like a common thread is a shortage of willing programming effort so that things may be maintained and improved. Would it be worth thinking about how to promote Haskell in communities where people might be willing and able to contribute to the work? (Much thanks to the people who are already part of it.) -- Mark
Olaf Chitil <olaf@cs.york.ac.uk> wrote,
Here a short summary by Malcolm and me of the final discussion at the Haskell workshop:
I also took a couple of notes which I like to add.
John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.)
In fact, the recent release of binary packages for Gtk+HS and an example applications that demonstrates how to use the GTK+ API in Haskell have been a reaction to the discussions at HW & ICFP. Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution. You can see how programs coded against the GTK+ API in Haskell look like at the following example: http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html (As for Unix/Win32 portability of GUI code, that's not great for C or C++ either.)
Rather than starting work on a successor to Haskell, people generally want to see `blessed addendums' to the Report, for common agreed extensions, e.g. FFI, exceptions, concurrency, MPTC, fundeps, etc. The FFI addendum is almost ready, but any others need volunteers, not to mention agreement between designers and implementations. The idea is that a solid reference definition/documentation of each extension should exist independent of any particular compiler (but there is a lack of volunteers).
It was noted that the future job of designing Haskell-2 will be made much easier by many small steps rather than one large effort.
Generally, as last year, there seemed to be not much interest to look into Haskell 2. Meanwhile, addenda to H98 seem to be a feasible alternative. In fact, one aim with the FFI Addendum was to create a precedent that can be repeated for other extensions. The nature of an addendum brings with it that the extension should be rather non-invasive. For example, in the case of the FFI, one new keyword (`foreign') is added, taking it from the pool of available variable identifiers. The rest of the functionality should not invalidate any existing H98 programs. As a consequence, the kind of extensions that can be realised in this way are limited. For example, extensions of the type system are much more likely to have a severe effect on existing H98 programs. So, they will be less easy to add in this form. It was also pointed out that we should go for an addendum only where - the design is clear and tested (example implementations exist and have been used in applications) and - where there is considerable demand. The first point is surely self-explanatory. As for the second, defining an addendum is a lot of work, which can be used better otherwise unless the extension is really important. Possible further addenda (in addition to the FFI), which have been mentioned, are the following: - The core library (in fact, there is already exists a task force to look into this extension) - Concurrency support (there just are applications that are virtually impossible to implement well without concurrency) - Exceptions (again a really elementary feature of modern languages) - Graphics library (obviously there is a lot of demand, but it is also a rather involved task) In my opinion, all the above functionality falls into the catergory embarrassing not to have. The lack therefore, in fact, promotes the image of Haskell being an academic toy language. The only exception is to a degree the graphics library (again my opinion, which obviouly is not shared by everybody, most notably John Launchbury). My reason is that, while access to GUI toolkits is a must, few languages standardise them. Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed. Moreover, they tend to be more invasive. Personally, I would believe that multi-parameter type classes may maybe be the most likely candidate for an addendum. There was the feeling that there is not frequent enough feedback from the "Task Forces" (eg, FFI Task Force, Library Task Force) to the Haskell community as a whole. Clause Reinke kindly volunteered to collect status reports of Task Forces on a 6-monthly basis and post them to the Haskell mailing list. Claus, maybe you should give the Task Forces an idea of when you expect the first status report.
Manuel Chakravarty: A standard Foreign Function Interface for Haskell98 Basically finished (general part and C, not for Java). Solicits last comments from the general community.
The plan is to have one last round of edits on the FFI list, and, then post the draft on the main Haskell list. (Should happen soon, but I am still trying to recover from jet lag and a huge pile of emails and todos that waited for me upon return from ICFP). Cheers, Manuel
Rather than talking about general features of the language that might improve adoption in general, it is more useful to talk about specific features of the language that make it killer in a particular application domain. In his classic book, "Crossing the Chasm : Marketing and Selling High-Tech Products to Mainstream Customers", Geoffrey Moore argues that the way to gain mainstream adoption of a new technology is to target specific segments of the customer population and to deliver whole product to them (because integration challenges are daunting). In http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt, Paul Graham argues that: One of the reasons to use Lisp in writing Web-based applications is that you *can* use Lisp. When you're writing software that is only going to run on your own servers, you can use whatever language you want. And further that: Until recently, writing application programs meant writing software to run on desktop computers. In desktop software there was a strong bias toward writing the application in the same language as the operating system. I would add that web based applications can use web interfaces and that HTML is a good interface to many applications. (and that Paul Graham's comments about Lisp are also true of Haskell) As such, I would like to see a focus on making Haskell great for web application and web service development. Some of the the pieces required are application level, some are libraries, and some are language features. Here is my quick take: Application Framework * a simple build/install process on both unix and win32 * a way to run/link haskell applications to a web server (apache) * a decent libary organization and CPAN-like library sharing system * a system for publishing apps to live servers Libraries * an OS file/directory access library * a database connection library (even just ODBC would be fine!) * a database connection pool library * a mail handling library * an XML parser library * an XML-RPC/SOAP library Language Features * concurrency (to make requests to multiple servers simultaneously) * FFI (to access libraries in other languages) * exceptions (may not matter depends on the webserver/haskell interface!) Documentation * an O'Reilly class book on learning and developing web apps in Haskell * sample applications that demonstrate useful web service functions * a process for managing Haskell web app development As a general matter, the addendum process strikes me as confusing and dangerous. I don't want to have a conversation like: I am using Haskell'98 with Addendum A, C, and E. I'd rather say, I am using Haskell 2001 and know that it is useful for developing web apps. I know this is a lot of work, but it was what you get from Python, Perl, and Java. If Haskell wants to compete in this arena, it needs to provide this level of service. Also, I think a lot of these exist in pieces, so the real work is in compiling it all into a good usable package. I am not volunteering to do it, but I would be happy to help beta if someone else does. -Alex- PS There may be other better/easier initial application domains for Haskell, but this is what I know. ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:
Olaf Chitil <olaf@cs.york.ac.uk> wrote,
Here a short summary by Malcolm and me of the final discussion at the Haskell workshop:
I also took a couple of notes which I like to add.
John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.)
In fact, the recent release of binary packages for Gtk+HS and an example applications that demonstrates how to use the GTK+ API in Haskell have been a reaction to the discussions at HW & ICFP.
Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution.
You can see how programs coded against the GTK+ API in Haskell look like at the following example:
http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html
(As for Unix/Win32 portability of GUI code, that's not great for C or C++ either.)
Rather than starting work on a successor to Haskell, people generally want to see `blessed addendums' to the Report, for common agreed extensions, e.g. FFI, exceptions, concurrency, MPTC, fundeps, etc. The FFI addendum is almost ready, but any others need volunteers, not to mention agreement between designers and implementations. The idea is that a solid reference definition/documentation of each extension should exist independent of any particular compiler (but there is a lack of volunteers).
It was noted that the future job of designing Haskell-2 will be made much easier by many small steps rather than one large effort.
Generally, as last year, there seemed to be not much interest to look into Haskell 2. Meanwhile, addenda to H98 seem to be a feasible alternative. In fact, one aim with the FFI Addendum was to create a precedent that can be repeated for other extensions.
The nature of an addendum brings with it that the extension should be rather non-invasive. For example, in the case of the FFI, one new keyword (`foreign') is added, taking it from the pool of available variable identifiers. The rest of the functionality should not invalidate any existing H98 programs. As a consequence, the kind of extensions that can be realised in this way are limited. For example, extensions of the type system are much more likely to have a severe effect on existing H98 programs. So, they will be less easy to add in this form.
It was also pointed out that we should go for an addendum only where
- the design is clear and tested (example implementations exist and have been used in applications) and
- where there is considerable demand.
The first point is surely self-explanatory. As for the second, defining an addendum is a lot of work, which can be used better otherwise unless the extension is really important.
Possible further addenda (in addition to the FFI), which have been mentioned, are the following:
- The core library (in fact, there is already exists a task force to look into this extension) - Concurrency support (there just are applications that are virtually impossible to implement well without concurrency) - Exceptions (again a really elementary feature of modern languages) - Graphics library (obviously there is a lot of demand, but it is also a rather involved task)
In my opinion, all the above functionality falls into the catergory embarrassing not to have. The lack therefore, in fact, promotes the image of Haskell being an academic toy language. The only exception is to a degree the graphics library (again my opinion, which obviouly is not shared by everybody, most notably John Launchbury). My reason is that, while access to GUI toolkits is a must, few languages standardise them.
Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed. Moreover, they tend to be more invasive. Personally, I would believe that multi-parameter type classes may maybe be the most likely candidate for an addendum.
There was the feeling that there is not frequent enough feedback from the "Task Forces" (eg, FFI Task Force, Library Task Force) to the Haskell community as a whole. Clause Reinke kindly volunteered to collect status reports of Task Forces on a 6-monthly basis and post them to the Haskell mailing list.
Claus, maybe you should give the Task Forces an idea of when you expect the first status report.
Manuel Chakravarty: A standard Foreign Function Interface for Haskell98 Basically finished (general part and C, not for Java). Solicits last comments from the general community.
The plan is to have one last round of edits on the FFI list, and, then post the draft on the main Haskell list. (Should happen soon, but I am still trying to recover from jet lag and a huge pile of emails and todos that waited for me upon return from ICFP).
Cheers, Manuel
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Thu, 13 Sep 2001, S. Alexander Jacobson wrote: (snip)
As such, I would like to see a focus on making Haskell great for web application and web service development. Some of the the pieces required are application level, some are libraries, and some are language features. Here is my quick take: (snip) I know this is a lot of work, but it was what you get from Python, Perl, and Java. If Haskell wants to compete in this arena, it needs to provide this level of service. Also, I think a lot of these exist in pieces, so the real work is in compiling it all into a good usable package. I am not (snip)
For what little it's worth, I'm encouraged just to see people talking like this lately: such things would make a lot of difference in making me much more comfortable about using Haskell for non-trivial commercial projects. -- Mark
Just a quick remark: S. Alexander Jacobson wrote (on 13-09-01 12:40 -0400):
As a general matter, the addendum process strikes me as confusing and dangerous. I don't want to have a conversation like: I am using Haskell'98 with Addendum A, C, and E. I'd rather say, I am using Haskell 2001 and know that it is useful for developing web apps.
Eventually, you will be saying that, but about Haskell-2. In the interim, having extensions described in addendums is probably better than the situation we have now, in which you are forced to say that "I am using Haskell with extension X" (but with whose semantics?) or "I am using GHC Haskell" (but Hugs also supports my extension). At least if an extension is described in a Haskell Report Addendum one knows where to look for its semantics, that its semantics are standardized, and that it is reasonably accepted by the community and not some Bizarro (I love that word :) extension which will only ever be implemented in some obscure researcher's pet compiler project. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379
As such, I would like to see a focus on making Haskell great for web application and web service development.
Right. On the server side, this is "easy" (and people have done it, see the example HTML server, and I've used it to code up a game server, used for a students' programming contest here (*)). I would love to see Haskell used on the client side, that is, I want Haskell applets. This would probably require that the user downloads Hugs as a netscape-plugin? Or ghc emits Java (byte-)code? And in both cases: what GUI should we use? In case you wonder - this application is "purely academic": the applets should help my students to understands certain concepts in theoretical computer science. Of course I would then welcome their questions on "how did you program this"... (for an example, see the PCP Puzzle http://www.informatik.uni-leipzig.de/~pcp/ but that is a Java program. I want to program exactly this kind of applet in Haskell!) (*) the server itself runs fine, but the Java applet to play/display games http://theopc.informatik.uni-leipzig.de/~connect/ currently is broken :-) -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
I would love to see Haskell used on the client side, that is, I want Haskell applets.
I know of one Haskell applet running on the internet.
This would probably require that the user downloads Hugs as a netscape-plugin? Or ghc emits Java (byte-)code? And in both cases: what GUI should we use?
There are proposals for java byte-code backends for ghc. However, there are currently no concrete products implementing such a backend. I know three links to papers in this area, the last one coming with a Haskell applet example. D. Wakeling wrote three papers which are available at http://www.dcs.ex.ac.uk/~david/en/research/previous/java/ Martijn de Vries wrote a paper which is at http://www.i2x.com/~martijn/ Alessandro Vernet wrote an article and a backend, but he mailed me he lost the backend due to a computer crash. http://www.scdi.org/~avernet/projects/jaskell/ Still, he has one haskell-applet (having the algorithm written in Haskell and the GUI written in Java) which survived the crash. It is running at http://www.scdi.org/~avernet/projects/jaskell/queens/ Rijk-Jan
On Thursday, 13. September 2001 17:50, Manuel M. T. Chakravarty wrote:
[...] Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution.
In my opinion GTK+ is not that nice to develop Win32 applications because it provides its own look-and-feel which conflicts with the one of Windows. On UNIX-like systems where each desktop environment has its own look-and-feel it does not conflict under GNOME because GNOME is based on it. That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different "native" libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library.
[...] Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed.
I need at least multi-parameter type classes urgently. I am currently working on a software package allowing website implementation in Haskell which relies on them.
[...]
Wolfgang
Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote,
That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different "native" libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library.
wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings. One alternative would be to standardise on a kind of subset of the GTK+ API and then somebody with a lot of spare time could implement that on top of the Win32 API natively - in the meantime, the original GTK+ libraries would at least provide some form of implementation under Win32. (You should bear in mind that anything that doesn't build on existing infrastructure involves a lot of coding and I haven't seen many volunteers stepping forward yet.) Manuel
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: (snip)
wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages (snip)
Of course, wxPython also exists - I assume that the emphasis on object orientation is the problem? -- Mark
Mark Carroll <mark@chaos.x-philes.com> wrote,
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: (snip)
wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages (snip)
Of course, wxPython also exists - I assume that the emphasis on object orientation is the problem?
Also, the lack of a static type system makes it easier to embed foreign APIs into Python. Manuel
Out of curiosity, how does GTK+ compare with Fruit? It seems like it would make sense for the standard Haskell GUI also to be functional. -Alex- PS I don't do GUI stuff so I don't really know much. I did read the Fruit paper and it looked interesting. On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:
Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote,
That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different "native" libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library.
wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings.
One alternative would be to standardise on a kind of subset of the GTK+ API and then somebody with a lot of spare time could implement that on top of the Win32 API natively - in the meantime, the original GTK+ libraries would at least provide some form of implementation under Win32. (You should bear in mind that anything that doesn't build on existing infrastructure involves a lot of coding and I haven't seen many volunteers stepping forward yet.)
Manuel
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)
"S. Alexander Jacobson" <alex@shop.com> wrote,
Out of curiosity, how does GTK+ compare with Fruit?
GTK+ has a C API heavily based on call backs and mutable state. Thus, the Haskell transcription of that API heavily relies on the use of the IO monad - as does H98 textual IO.
It seems like it would make sense for the standard Haskell GUI also to be functional.
A functional GUI would be nice, but standard Haskell text and file I/O is not functional either. Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later. Cheers, Manuel
Manuel:
... Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later.
just to voice a slightly differnt opinion: I worked with FranTk a bit and found it quite easy to handle. There are some technical problems maybe, but they do not come from the design but rather from using Tcl/Tk. The design itself is rather abstract (that's the very intention), and is not tied to one particular backend. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> wrote,
Manuel:
... Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later.
just to voice a slightly differnt opinion: I worked with FranTk a bit and found it quite easy to handle. There are some technical problems maybe, but they do not come from the design but rather from using Tcl/Tk. The design itself is rather abstract (that's the very intention), and is not tied to one particular backend.
Hmm, I didn't mention FranTk in the cited paragraph. Fruit and FranTk are rather different. Manuel
If the GUI is based on the IO monad, then it doesn't seem like there is a lot of advantage to doing it in Haskell. It seems like a better idea to use a more natural language for IO and make RPC/interproc calls to a haskell server to get stuff done. In other words, what is the value of the GTK+ haskell interface? Shouldn't more effort be put into getting Fruit production quality and/or figuring out how to use arrows to manage textual and network IO? -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:
"S. Alexander Jacobson" <alex@shop.com> wrote,
Out of curiosity, how does GTK+ compare with Fruit?
GTK+ has a C API heavily based on call backs and mutable state. Thus, the Haskell transcription of that API heavily relies on the use of the IO monad - as does H98 textual IO.
It seems like it would make sense for the standard Haskell GUI also to be functional.
A functional GUI would be nice, but standard Haskell text and file I/O is not functional either. Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later.
Cheers, Manuel
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
If the GUI is based on the IO monad, then it doesn't seem like there is a lot of advantage to doing it in Haskell. It seems like a better idea to use a more natural language for IO and make RPC/interproc calls to a haskell server to get stuff done.
In other words, if you use the IO monad, you're going to have the same programming experience (only more verbose) as a C/C++/Java programmer? I don't think that's true. My graphics library (http://haskell.org/graphics/) uses the IO monad for manipulating windows and the Draw monad for doing graphics but both feel quite different from similar code I've written in C (and, I believe, from C++ or Java code). In the case of manipulating windows, the different feel comes from using concurrency to "hide the event loop" and from using layers of abstraction to hide the full power (and horror) of the X and Win32 programming models. In the case of the Draw monad (which is identical to the IO monad except that it carries a "device context" around as an implicit parameter), the different feel comes from aggressive use of continuations (actually, they're not quite continuations but I don't have a better word for them). For example, you might normally write code like this: do old_color <- selectColor blue old_font <- selectFont helvetica write_text "Hello World" selectFont old_font selectColor old_color (Reselecting the old color and font at the end is recommended Win32 programming style.) In the HGL, you instead write: setPicture window (withColor blue (withFont helvetica (text "Hello World"))) or, equivalently but allegedly easier to read, setPicture window $ withColor blue $ withFont helvetica $ text "Hello World" where withColor and withFont are defined like this: withColor :: Color -> Draw a -> Draw a withColor c m = do{ old <- selectColor c; a <- m; selectColor old; return a } withFont :: Font -> Draw a -> Draw a withFont f m = do{ old <- selectFont f; a <- m; selectFont old; return a } and setPicture exploits the fact that an object of type "Draw a" is a first class object which can be stored in the window state and executed when appropriate (e.g., when the window is uniconified). What I'm saying is that Haskell's standard abstraction facilities mean that even in the IO monad your programming experience can significantly better than that of a C programmer. (Of course your experience can also be worse if you don't or can't bring Haskell's strengths to bear on your problem.) -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
"S. Alexander Jacobson" <alex@shop.com> wrote,
If the GUI is based on the IO monad, then it doesn't seem like there is a lot of advantage to doing it in Haskell. It seems like a better idea to use a more natural language for IO and make RPC/interproc calls to a haskell server to get stuff done.
I completely disagree - with SimonPJ's words (I think from the "Awkward Squad" paper), ``Haskell is the world's finest imperative programming language.'' Side effects are one thing, but having Haskell type system and support for higher-order functions available makes imperative programming so much nice. For example, proper support for closures makes the whole signal handling code needed for GTK+-based GUIs much nicer in Haskell than in C. And this is not just idle theory. Most of the code in Gtk+HS lives in the IO monad and and it's a considerable amount of code. I came to the stated opinion after having written that. Cheers, Manuel
On Friday, 14. September 2001 04:38, you wrote:
[...] wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings.
I didn't mean that a Haskell binding to wxWindows should be made. I meant that the strategy of wxWindows should be used also for a Haskell GUI library. This strategy is to define a common GUI interface and provide implementations for different platforms based on different libraries like GTK+ (for GNOME), Qt (for KDE), Win32. By the way a Haskell binding to wxWindows would maybe cause performance problems just because wxWindows isn't "native" but itself uses other GUI libraries. Wolfgang
At 09:58 14-9-01 +0200, Wolfgang Jeltsch wrote:
I didn't mean that a Haskell binding to wxWindows should be made. I meant that the strategy of wxWindows should be used also for a Haskell GUI library. This strategy is to define a common GUI interface and provide implementations for different platforms based on different libraries like GTK+ (for GNOME), Qt (for KDE), Win32.
This strategy has been followed by the pilot project that has been described in [1]. In this project we have ported a crucial subset of the Clean Object I/O library to Haskell. The Clean Object I/O library is used for major projects such as the Clean IDE and the Clean theorem prover SPARKLE by Maarten de Mol. The pilot port has been done on a Windows platform, so that we could reuse the primitive implementation layer. To port it to a more Unix friendly environment, I guess Manuel Chakravarty's GTK binding library is very well suited. You can find the results from the pilot project in the GHC CVS repository at fptools/hslibs/object-io The current state of affairs is due to severe lack of time a little unsatisfactory... To make this project manageable, it would be good to have some kind of automatic translator (nothing fancy, just a specialised translator from Clean Object I/O to Haskell Object I/O would do) that will derive the Haskell version from the Clean version that I do maintain. I haven't had time yet to make such a tool. Regards, Peter Achten ------------------ [1] Peter Achten and Simon Peyton Jones, "Porting the Clean Object I/O Library to Haskell", in Mohnen, M. and Koopman, P. (eds) Proceedings of 12th International Workshop Implementation of Functional Languages, IFL2000, Aachen, Germany, September 2000, Selected Papers, Springer, LNCS 2011, pp. 194-213. ftp://ftp.cs.kun.nl/pub/Clean/papers/2001/achp2001-HaskellObjectIO.ps.gz ftp://ftp.cs.kun.nl/pub/Clean/papers/2001/achp2001-HaskellObjectIO.pdf
participants (12)
-
Alastair David Reid -
Frank Atanassow -
Johannes Waldmann -
kahl＠heraklit.informatik.unibw-muenchen.de -
Manuel M. T. Chakravarty -
Mark Carroll -
Olaf Chitil -
Peter Achten -
Rijk-Jan van Haaften -
S. Alexander Jacobson -
S.J.Thompson＠ukc.ac.uk -
Wolfgang Jeltsch