Namespaces (was Re: GUI Library Task Force)
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ~~ Hal Daume III [EMAIL PROTECTED] arrest this man, he talks in maths www.andrew.cmu.edu/~hcd ~~ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Namespaces (was Re: GUI Library Task Force)
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Namespaces (was Re: GUI Library Task Force)
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ~~ Hal Daume III [EMAIL PROTECTED] arrest this man, he talks in maths www.andrew.cmu.edu/~hcd ~~ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Namespaces (was Re: GUI Library Task Force)
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. - [EMAIL PROTECTED] --- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
Lennart Augustsson [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
Great. So that is something that goes into some library conventions document. Such a document is here: http://www.haskell.org/~simonmar/libraries/libraries.html If there are comments on the design (which is by no means finalised), please take them to the libraries mailing list. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
At 18:53 25-9-01 +1000, Manuel Chakravarty wrote: Simon Peyton-Jones [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
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. I don't think anyone is suggesting that we change the meaning of the term Haskell 98: it is, and always will be, defined by the Haskell 98 report. The idea behind addenda to the report is to define a family of new languages, eg. Haskell 98 + FFI, Haskell 98 + FFI + Exceptions, and so on. These languages may be incompatible with pure Haskell 98, but compilers will generally give you the choice between pure Haskell 98 and whatever extensions are supported. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
Ian Lynagh [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
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 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
Simon Peyton-Jones [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
At 2001-09-25 01:53, 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. Heh. I had to do this for JVM-Bridge because all the JNI functions need the JavaVM. A bit like this: data JVM a = MkJVM (JavaVM - IO a) instance Monad JVM where etc. ...actually there's more to the 'context' than that, but you get the idea. Of course there's a 'callIO' function to make lifting as painless as possible. On the other hand with the full Java API hopefully there's less necessity to use normal IO at all anymore so perhaps it will be less of an issue. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
| *** 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
