| *** The GUI Library Task Force Strategy Proposal *** Great! | * Start from the API of GTK+ as a base line: That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.) The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe. I wondered whether its design would not "fit" Haskell because of the different approaches to I/O, but that turned out not to be an issue. There's a paper that introduces the Haskell rendering of the Clean library at http://research.microsoft.com/~simonpj/papers/haskellobjectio.htm Simon
"Simon Peyton-Jones" <simonpj@microsoft.com> wrote,
| * Start from the API of GTK+ as a base line:
That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.)
The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe.
I have looked at the Clean Object IO. While it is certainly worthwhile to take from this approach whatever we can, I have a number of reasons why I am not convinced that the model itself should be adopted for the Haskell GUI: * Non-standard extensions: It requires concurrency and judging by Section 6 rank-2 polymorphism. I am not quite sure how crucial the later is. * It integrates facilities for concurrent and distributed programming (asynchronous communication via channels). I still think, we can keep the GUI API and concurrency as two orthogonal features. If you take these features out and use IORefs instead of MVars, you are already quite close to the model that we currently aim at. * I am not a big fan of introducing an extra monad (`GUI' in this case). It can easily become a pain in programs that do a lot of "normal" IO as you have to lift all IO functions to GUI. * After this, the main difference that remains is the representation of GUI components as a vanilla data type instead of opaque handles that do not make the structure of the components explicit in the types (like the TupLS does). From the paper, it wasn't clear to me how useful that is for the application programmer. Cheers, Manuel
Given that Haskell98 is not ready for libraries anyway, why are you so concerned about it? A GUI system without concurrency is still incomplete. The haskell library interface story is still pretty weak because there is no consensus about what monad they should expose (and whether they should really expose arrows or something else). Why not focus on rolling from H98 into a production quality Haskell system and make the best GUI for that system? -Alex- On Tue, 25 Sep 2001, Manuel M. T. Chakravarty wrote:
"Simon Peyton-Jones" <simonpj@microsoft.com> wrote,
| * Start from the API of GTK+ as a base line:
That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.)
The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe.
I have looked at the Clean Object IO. While it is certainly worthwhile to take from this approach whatever we can, I have a number of reasons why I am not convinced that the model itself should be adopted for the Haskell GUI:
* Non-standard extensions: It requires concurrency and judging by Section 6 rank-2 polymorphism. I am not quite sure how crucial the later is.
* It integrates facilities for concurrent and distributed programming (asynchronous communication via channels). I still think, we can keep the GUI API and concurrency as two orthogonal features. If you take these features out and use IORefs instead of MVars, you are already quite close to the model that we currently aim at.
* I am not a big fan of introducing an extra monad (`GUI' in this case). It can easily become a pain in programs that do a lot of "normal" IO as you have to lift all IO functions to GUI.
* After this, the main difference that remains is the representation of GUI components as a vanilla data type instead of opaque handles that do not make the structure of the components explicit in the types (like the TupLS does). From the paper, it wasn't clear to me how useful that is for the application programmer.
Cheers, 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,
Given that Haskell98 is not ready for libraries anyway, why are you so concerned about it?
It isn't? Why? Because of the lack of hierachical name spaces? Then, C isn't ready for libraries either.
A GUI system without concurrency is still incomplete.
There are loads of large GUI-based applications out there that don't use concurrency. BTW, my point was not to say that we rule out concurrency. I said, we do not demand it. (Same as in many GUI libraries for the most widespread imperative languages.)
The haskell library interface story is still pretty weak because there is no consensus about what monad they should expose (and whether they should really expose arrows or something else). Why not focus on rolling from H98 into a production quality Haskell system and make the best GUI for that system?
Currently, there doesn't seem to be much interest in going for a completely new version of Haskell. The idea of adding addenda to H98 and so slowly and in incremental steps move to more functionality seems to be more popular. One reason for this is that there is significant investment in H98, in terms of documentation, textbooks, compilers, and tools. Cheers, Manuel
On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
Given that Haskell98 is not ready for libraries anyway, why are you so concerned about it?
It isn't? Why? Because of the lack of hierachical name spaces? Then, C isn't ready for libraries either.
As I posted in a prior thread: * Library namespace is broken So is C's, however it relies MUCH more strongly on build tools like Make. All popular languages that have been created in the last 20 years appear to have saner systems (Java, Perl, Python, etc). The problem is worse in Haskell because the number of built in libraries is very small and the code reuse goals are much more ambitious. * Library Interfaces This is a much bigger issue for Haskell than C. Are they monadic and which monad and should they really be arrows but then they will rely on non-standard syntax, etc.
A GUI system without concurrency is still incomplete.
There are loads of large GUI-based applications out there that don't use concurrency.
BTW, my point was not to say that we rule out concurrency. I said, we do not demand it. (Same as in many GUI libraries for the most widespread imperative languages.)
Haskell will not be production quality without concurrency. If concurreny allows for a cleaner API and easier to use library, then use it. BeOS had deep concurrency throughout and was a much better OS as a result. Its 2001, there is no reason I shouldn't be able to have two threads drawing things on the screen simultaneously. If the issue is that we still don't know how to do concurrency in Hasskell, that seems like a MUCH higher priority than sorting out GUIs.
The haskell library interface story is still pretty weak because there is no consensus about what monad they should expose (and whether they should really expose arrows or something else). Why not focus on rolling from H98 into a production quality Haskell system and make the best GUI for that system?
Currently, there doesn't seem to be much interest in going for a completely new version of Haskell. The idea of adding addenda to H98 and so slowly and in incremental steps move to more functionality seems to be more popular.
Thats great. I don't disagree. Its just a matter of priority. So how about this agenda? Addendum .5?: Parametrized Libraries Addendum 1: Hierarchical Library Namespace Addendum 2: Concurrency Addendum 3: FFI Addendum 4: Exceptions Addendum 4.5?: Proc Syntax for Arrows Addendum 5: Library Interface Compatibility Guidelines Addendum 6: Enumeration of standard Haskell libraries (GUI etc) If we could focus on converging these addenda rapidly and in a particular order, then Haskell could reach a much better place much more quickly. Many of these things are individually small changes from H98, but together they make it a much stronger language. -Alex- PS I don't know if this agenda is in the right order. I do think that everyone randomly thrashing about with different language features will make everything take much longer. ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)
"S. Alexander Jacobson" wrote:
Haskell will not be production quality without concurrency. If concurreny allows for a cleaner API and easier to use library, then use it. BeOS had deep concurrency throughout and was a much better OS as a result. Its 2001, there is no reason I shouldn't be able to have two threads drawing things on the screen simultaneously.
If the issue is that we still don't know how to do concurrency in Hasskell, that seems like a MUCH higher priority than sorting out GUIs.
May I add my vote of agreement. The concurrency abstractions in the GHC libraries are very fine indeed. However, a GHC thread calling into the non-Haskell world blocks all other threads until it returns, and experiment suggests that non-Haskell threads calling into the GHC world are unable to interact freely with other GHC threads. Forging a peer relationship between Haskell and non-Haskell threads would enable whole new classes of applications. For example, a Haskell thread could call into the OS and wait for the next GUI event, and a Haskell IO action could be registered with the OS for callback when certain GUI events occur. -- Tim Sauerwein / Galois Connections Inc.
"S. Alexander Jacobson" wrote:
On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
Given that Haskell98 is not ready for libraries anyway, why are you so concerned about it?
It isn't? Why? Because of the lack of hierachical name spaces? Then, C isn't ready for libraries either.
As I posted in a prior thread: * Library namespace is broken So is C's, however it relies MUCH more strongly on build tools like Make. All popular languages that have been created in the last 20 years appear to have saner systems (Java, Perl, Python, etc). The problem is worse in Haskell because the number of built in libraries is very small and the code reuse goals are much more ambitious.
Yes, the Library namespace is not ideal, and there has been a suggestion to add `.' to module names to solve this. If we don't want to do that, just use `_' as a name separator instead of `.'. This way you can build hierarchies. -- Lennart
Great. So that is something that goes into some library conventions document. Java has a convention that libraries should have reverse domain name structure. Is that how we should use _? -Alex- On Wed, 26 Sep 2001, Lennart Augustsson wrote:
"S. Alexander Jacobson" wrote:
On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
Given that Haskell98 is not ready for libraries anyway, why are you so concerned about it?
It isn't? Why? Because of the lack of hierachical name spaces? Then, C isn't ready for libraries either.
As I posted in a prior thread: * Library namespace is broken So is C's, however it relies MUCH more strongly on build tools like Make. All popular languages that have been created in the last 20 years appear to have saner systems (Java, Perl, Python, etc). The problem is worse in Haskell because the number of built in libraries is very small and the code reuse goals are much more ambitious.
Yes, the Library namespace is not ideal, and there has been a suggestion to add `.' to module names to solve this. If we don't want to do that, just use `_' as a name separator instead of `.'. This way you can build hierarchies.
-- Lennart
___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)
"S. Alexander Jacobson" wrote:
Great. So that is something that goes into some library conventions document. Java has a convention that libraries should have reverse domain name structure. Is that how we should use _?
Yes, I think that could be the way. And in addition there should be some language libraries (just like Java has java.*). -- Lennart
Lennart Augustsson <lennart@augustsson.net> writes:
"S. Alexander Jacobson" wrote:
Great. So that is something that goes into some library conventions document. Java has a convention that libraries should have reverse domain name structure. Is that how we should use _?
Yes, I think that could be the way. And in addition there should be some language libraries (just like Java has java.*).
Even if . is used as hierarchy separator, I think one might consider using a _ for the top level reverse DNS hierarchy, instead of blindly following the Java example. I.e. instead of No.Nera..., use Nera_No at the top level. I think this has a couple of advantages: - less chance of a name clash - sorting by "real" name Ther former is probably the more important, when ICANN in their infinite wisdom invents new top level domains to broaden the hierarchy, in order to solve the problems caused by the hierarchy's shallowness... Anyway, I think it would be nice to be able to use short, concise hierarchy names like "Std" or "Sys" without worrying about the capriciocities of the net. Having stuff from postgresql.com and postgresql.org grouped near each other sounds attractive, too. The downside is a wider hierarchy, but I think that most installations would only include packages from a handful of third parties anyway, and third parties submitting modules that many need, should have them standardized into the main tree. One could of course group all third parties under a Contrib branch in order to remove top-level clutter. It is quite possible that I'm missing out on some important advantage of the Java scheme, but I haven't seen it come up in the discussion, and would like alternatives to at least be considered before turned down. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
I think one important aspect of Java's java.foo.bar style has been overlooked: the semantics. sure, syntactivally, java.foo.bar and java_foo_bar; they're basically the same. the big issue (to me, at least) is that the Java compiler knows how to interpret the "."s and will use them to navigate directory structure. This ability is one of the little things in Haskell that could be "fixed" fairly easily (I can't see that it would break any existing programs) and would make my Haskelling experience MUCH more plesant. - Hal On Wed, 26 Sep 2001, Lennart Augustsson wrote:
"S. Alexander Jacobson" wrote:
Great. So that is something that goes into some library conventions document. Java has a convention that libraries should have reverse domain name structure. Is that how we should use _?
Yes, I think that could be the way. And in addition there should be some language libraries (just like Java has java.*).
-- Lennart
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hal Daume III hal@cmu.edu "arrest this man, he talks in maths" www.andrew.cmu.edu/~hcd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 10 Oct 2001, Hal Daume III wrote: (snip)
least) is that the Java compiler knows how to interpret the "."s and will use them to navigate directory structure. (snip)
Yes, that's certainly an interesting idea. I'd like to fall short of mandating anything about location of source files in any language spec, though: although I can see that people probably find Java's imposed semantics useful, personally I find them irritating and wouldn't want to shackle everyone to them. -- Mark
So, barring this, I'm curious how other people handle this issue. I have multiple projects. Call them A, B, C. They are in directories: ~/projects/A ~/projects/B ~/projects/C repsectively. Say I'm creating a new project, D, in ~/projects/D that uses code that I've written in packages A, B and C. Now, as far as I can see, I have two options: 1) Copy all the .(l)hs files from /A, /B, and /C to /D that I need to import 2) Include projects/A, projects/B and projects/C in my search path for ghc(i) I hate both of these options. 1 is terrible because I have multiple copies of the same code lying around and, if I make changes to one, I have to remember to copy the changes over to the others. 2 is a big nuisance, especially since ghc (seems to) lack an environment variable that it looks at to get command line options every time it runs (HUGSFLAGS, I think it was for Hugs). So is there a third option that I'm missing? How do other people handle this issue? - Hal On Wed, 10 Oct 2001, Mark Carroll wrote:
On Wed, 10 Oct 2001, Hal Daume III wrote: (snip)
least) is that the Java compiler knows how to interpret the "."s and will use them to navigate directory structure. (snip)
Yes, that's certainly an interesting idea. I'd like to fall short of mandating anything about location of source files in any language spec, though: although I can see that people probably find Java's imposed semantics useful, personally I find them irritating and wouldn't want to shackle everyone to them.
-- Mark
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hal Daume III hal@cmu.edu "arrest this man, he talks in maths" www.andrew.cmu.edu/~hcd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, Oct 10, 2001 at 03:29:03PM -0400, Hal Daume III wrote:
So, barring this, I'm curious how other people handle this issue.
I have multiple projects. Call them A, B, C. They are in directories: ~/projects/A ~/projects/B ~/projects/C repsectively.
Say I'm creating a new project, D, in ~/projects/D that uses code that I've written in packages A, B and C. Now, as far as I can see, I have two options:
1) Copy all the .(l)hs files from /A, /B, and /C to /D that I need to import 2) Include projects/A, projects/B and projects/C in my search path for ghc(i)
I hate both of these options. 1 is terrible because I have multiple copies of the same code lying around and, if I make changes to one, I have to remember to copy the changes over to the others. 2 is a big nuisance, especially since ghc (seems to) lack an environment variable that it looks at to get command line options every time it runs (HUGSFLAGS, I think it was for Hugs).
So is there a third option that I'm missing? How do other people handle this issue?
Personally I use symbolic links, either to the file or to the whole directory. This is not ideal since i cannot easily see which projects depend on a given file but at least all the dependencies of a project are visible under one directory without having to reverse-engineer the makefile. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@repetae.net ---------------------------------------------------------------------------
On Wednesday, October 10, 2001, at 12:29 PM, Hal Daume III wrote:
So, barring this, I'm curious how other people handle this issue.
I have multiple projects. Call them A, B, C. They are in directories: ~/projects/A ~/projects/B ~/projects/C repsectively.
Say I'm creating a new project, D, in ~/projects/D that uses code that I've written in packages A, B and C. Now, as far as I can see, I have two options:
1) Copy all the .(l)hs files from /A, /B, and /C to /D that I need to import 2) Include projects/A, projects/B and projects/C in my search path for ghc(i)
I hate both of these options. 1 is terrible because I have multiple copies of the same code lying around and, if I make changes to one, I have to remember to copy the changes over to the others. 2 is a big nuisance, especially since ghc (seems to) lack an environment variable that it looks at to get command line options every time it runs (HUGSFLAGS, I think it was for Hugs).
So is there a third option that I'm missing? How do other people handle this issue?
- Hal
Using the new hirarchical module namespace soon to be supported by both Hugs and GHC: Set the search path to ~/projects and import A.M, B.N, etc. The only additional requirement here is that your module M in A must be renamed A.M, and so forth. How does that sound? -- Johan
On Wed, 10 Oct 2001, Johan Nordlander wrote:
Using the new hirarchical module namespace soon to be supported by both Hugs and GHC:
Set the search path to ~/projects and import A.M, B.N, etc.
The only additional requirement here is that your module M in A must be renamed A.M, and so forth.
How does that sound?
That sounds wonderful! Is it available now? And could it deal with A.B.M if M is in /A/B? If not available now, how much longer? :) - Hal, who is happy one of his biggest surface pet peeves about Haskell is being remedied ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hal Daume III hal@cmu.edu "arrest this man, he talks in maths" www.andrew.cmu.edu/~hcd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Set the search path to ~/projects and import A.M, B.N, etc.
The only additional requirement here is that your module M in A must be renamed A.M, and so forth.
That sounds wonderful! Is it available now?
Yes, it has been supported in nhc98 since January 2001, and in ghc since August 2001. I'm not sure if Hugs has it yet.
And could it deal with A.B.M if M is in /A/B?
Yes, exactly so. Regards, Malcolm
On Wednesday, October 10, 2001, at 05:09 PM, Hal Daume III wrote:
That sounds wonderful! Is it available now? And could it deal with A.B.M if M is in /A/B? If not available now, how much longer? :)
The new version of Hugs that supports this extension isn't yet released, but you can easily grab it from cvs.haskell.org and and try it out today. And yes, A.B.M is searched for in searchpath/A/B/M.hs. -- Johan
On 10-Oct-2001, Hal Daume III <hcd@andrew.cmu.edu> wrote:
So, barring this, I'm curious how other people handle this issue.
I have multiple projects. Call them A, B, C. They are in directories: ~/projects/A ~/projects/B ~/projects/C repsectively.
Say I'm creating a new project, D, in ~/projects/D that uses code that I've written in packages A, B and C. Now, as far as I can see, I have two options:
1) Copy all the .(l)hs files from /A, /B, and /C to /D that I need to import 2) Include projects/A, projects/B and projects/C in my search path for ghc(i)
I hate both of these options. 1 is terrible because I have multiple copies of the same code lying around and, if I make changes to one, I have to remember to copy the changes over to the others. 2 is a big nuisance, especially since ghc (seems to) lack an environment variable that it looks at to get command line options every time it runs (HUGSFLAGS, I think it was for Hugs).
Well, I wouldn't be invoking ghc manually anyway; I'd put the commands to invoke ghc in a script or, more likely, in a Makefile. -- Fergus Henderson <fjh@cs.mu.oz.au> | "... it seems to me that 15 years of The University of Melbourne | email is plenty for one lifetime." WWW: <http://www.cs.mu.oz.au/~fjh> | -- Prof. Donald E. Knuth
On Wed, Sep 26, 2001 at 10:59:55PM +1000, Manuel M. T. Chakravarty wrote:
Currently, there doesn't seem to be much interest in going for a completely new version of Haskell. The idea of adding addenda to H98 and so slowly and in incremental steps move to more functionality seems to be more popular.
The preface of the report says Haskell has evolved continuously since its orignal publication. By the middle of 1997, there had been four versions of the language (the latest at that point being Haskell 1.4). At the 1997 Haskell Workshop in Amsterdam, it was decided that a stable variant of Haskell was needed; this stable language is the subject of this Report, and is called "Haskell 98". Haskell 98 was conceived as a relatively minor tidy-up of Haskell 1.4, making some simplifications, and removing some pitfalls for the unwary. It is intended to be a "stable" language in sense the implementors are committed to supporting Haskell 98 exactly as specified, for the foreseeable future. I don't think this is compatible with things like adding support for the library hierarchy with multiple dots to Haskell 98 as you will then be able to write a program that is valid Haskell 98 by todays definition but not yesterdays. OTOH if what you mean is adding support incrementally to todays *tools* and declaring H98 with a set of the new features to be Haskell 2 at some point in the future then I don't have a problem with that. Incidentally "orignal" is spelt wrong in the first line. Thanks Ian
Ian Lynagh <igloo@earth.li> wrote,
On Wed, Sep 26, 2001 at 10:59:55PM +1000, Manuel M. T. Chakravarty wrote:
Currently, there doesn't seem to be much interest in going for a completely new version of Haskell. The idea of adding addenda to H98 and so slowly and in incremental steps move to more functionality seems to be more popular.
The preface of the report says
Haskell has evolved continuously since its orignal publication. By the middle of 1997, there had been four versions of the language (the latest at that point being Haskell 1.4). At the 1997 Haskell Workshop in Amsterdam, it was decided that a stable variant of Haskell was needed; this stable language is the subject of this Report, and is called "Haskell 98".
Haskell 98 was conceived as a relatively minor tidy-up of Haskell 1.4, making some simplifications, and removing some pitfalls for the unwary. It is intended to be a "stable" language in sense the implementors are committed to supporting Haskell 98 exactly as specified, for the foreseeable future.
I don't think this is compatible with things like adding support for the library hierarchy with multiple dots to Haskell 98 as you will then be able to write a program that is valid Haskell 98 by todays definition but not yesterdays. OTOH if what you mean is adding support incrementally to todays *tools* and declaring H98 with a set of the new features to be Haskell 2 at some point in the future then I don't have a problem with that.
The latter. H98 as such will remain untouched. Cheers, Manuel
"Manuel M. T. Chakravarty" wrote:
* I am not a big fan of introducing an extra monad (`GUI' in this case). It can easily become a pain in programs that do a lot of "normal" IO as you have to lift all IO functions to GUI.
Shouldn't GUI be a typeclass (as a subclass of Monad), with IO being an instance of it? This gives the following benefits: o "Pure" GUI functions can reflect this in their type. i.e. (GUI g) => g () o IO functions can use GUI features directly without lifting. o "Pure" GUI functions are implicitly usable in the IO monad They "are" IO functions. Regards, Matt
At 18:53 25-9-01 +1000, Manuel Chakravarty wrote:
"Simon Peyton-Jones" <simonpj@microsoft.com> wrote,
| * Start from the API of GTK+ as a base line:
That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.)
The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe.
I have looked at the Clean Object IO. While it is certainly worthwhile to take from this approach whatever we can, I have a number of reasons why I am not convinced that the model itself should be adopted for the Haskell GUI:
* Non-standard extensions: It requires concurrency and judging by Section 6 rank-2 polymorphism. I am not quite sure how crucial the later is.
This is not what it says in the paper. Clean doesn't have concurrency and rank-2 polymorphism. In the paper we explicitly state that we wanted to play with GHC features, but none of these are necessary to implement Object I/O in Haskell. The only exception to the rule are existential types. In this sense I agree with Alexander Jacobson, who wrote:
I was opposing constraining it to H98 as it exists today rather than what we can reasonably expect it to be fairly shortly.
To restate: If the GUI effort can get done either more quickly, more elegantly, or with a nicer API, using some features that we all expect Haskell to have very shortly (as addenda), it should use them. (Especially if the timeline for completion of the GUI basically matches the timeline for these features to be added to Haskell.)
Even existential types are not really needed. Existential types, in the way they are used in the Object I/O library, can be completely implemented via functions. Clean Object I/O also existed before we had existential types... . However, existential types are infinitely more elegant and easy and readable and efficient (etc...) to use than this programming technique.
* It integrates facilities for concurrent and distributed programming (asynchronous communication via channels). I still think, we can keep the GUI API and concurrency as two orthogonal features. If you take these features out and use IORefs instead of MVars, you are already quite close to the model that we currently aim at.
As said, you don't need concurrency.
* I am not a big fan of introducing an extra monad (`GUI' in this case). It can easily become a pain in programs that do a lot of "normal" IO as you have to lift all IO functions to GUI.
This occurs only on the outermost level. I am always in favor of better solutions. Simon and I have looked if we could use an 'automatic' approach using functional dependencies, but then this would use another extension.
* After this, the main difference that remains is the representation of GUI components as a vanilla data type instead of opaque handles that do not make the structure of the components explicit in the types (like the TupLS does). From the paper, it wasn't clear to me how useful that is for the application programmer.
You are right. This was not the point of this particular paper. More about this matter appeared in: ------------ Achten, P. and Plasmeijer, R. Interactive Functional Objects in Clean. In Clack, C., Hammond, K., Davie, T. eds. Proceedings of the 9th International Workshop Implementation of Functional Languages, IFL'97, St.Andrews, Scotland, UK, September 1997, Selected papers, LNCS 1467, Springer, pp. 304-321. ------------ Regards, Peter Achten
"Manuel M. T. Chakravarty" wrote:
* After this, the main difference that remains is the representation of GUI components as a vanilla data type instead of opaque handles that do not make the structure of the components explicit in the types (like the TupLS does). From the paper, it wasn't clear to me how useful that is for the application programmer.
It seems to me that making GUI components data-types helps: -- allowing users change the layout of their app so that they can format the information the app provides according to their needs. Simple example from a debugger: allow the user to associate regions of code (or instructions from the instruction stream) with displaying of the FPU registers on the screen. -- saving/restoring the layout of the app as customized by the user. Sengan
participants (16)
-
Fergus Henderson -
Hal Daume III -
Ian Lynagh -
Johan Nordlander -
John Meacham -
Ketil Malde -
Lennart Augustsson -
Malcolm Wallace -
Manuel M. T. Chakravarty -
Mark Carroll -
Matt Harden -
Peter Achten -
S. Alexander Jacobson -
Sengan -
Simon Peyton-Jones -
Tim Sauerwein