- GUI - Haskell.org

RE: [GUI] Clean ObjectIO
by Simon Peyton-Jones 02 Oct '01

02 Oct '01

Krasimir: Great! Instructions for getting CVS access are on the GHC home page (CVS cheat sheet). The ObjectIO stuff is in fptools/hslibs/object-io Jeff: could you let him have access, please? thanks SImon | -----Original Message----- | From: Krasimir Angelov [mailto:ka2_mail@yahoo.com] | Sent: 27 September 2001 19:07 | To: Simon Peyton-Jones | Cc: gui(a)haskell.org | Subject: RE: [GUI] Clean ObjectIO | | | | --- Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: | > Oh yes! | > | > The ObjectIO port is in the "fptools" CVS | > repository. I would | > dearly like to give you write access to (that part | > of) it, so you can | > work on it "in situ". That way everyone will get the | > benefit of | > your work. | > | > Would you like to do this? | | Yes. I will be happy to share my expirience with you. | | Krasimir | | __________________________________________________ | Do You Yahoo!? | Listen to your Yahoo! Mail messages from any phone. | http://phone.yahoo.com |

1 0

RE: [GUI] Clean ObjectIO
by Simon Peyton-Jones 28 Sep '01

28 Sep '01

Oh yes! The ObjectIO port is in the "fptools" CVS repository. I would dearly like to give you write access to (that part of) it, so you can work on it "in situ". That way everyone will get the benefit of your work. Would you like to do this? Simon | -----Original Message----- | From: Krasimir Angelov [mailto:ka2_mail@yahoo.com] | Sent: 26 September 2001 15:56 | To: gui(a)haskell.org | Subject: [GUI] Clean ObjectIO | | | I have extended version of haskellised ObjectIO | library. She is based on original "Port of the Clean | Object I/O library to Haskell", but now support many | other thinks: | | ComboBox, CheckControl, RadioControl, Slider ... | Draw monad and initial support of windows | | Is there any interested about this | | __________________________________________________ | Do You Yahoo!? | Get email alerts & NEW webcam video instant messaging with | Yahoo! Messenger. http://im.yahoo.com | | _______________________________________________ | GUI mailing list | GUI(a)haskell.org | http://www.haskell.org/mailman/listinfo/gui |

2 1

Re: GUI Library Task Force
by Manuel M. T. Chakravarty 28 Sep '01

28 Sep '01

[redirected to the GUI mailing list] Matt Harden <matth(a)mindspring.com> wrote, > "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. That's an interesting idea. The main problem that I am seeing at the moment is that the basic GUI functionality that usually is imported from C libraries via the FFI will be in IO. That's because foreign imports of sideeffecting functions (which almost all basic GUI functions are) are required to be of type `a -> IO b'. This constraints the GUI monad to be IO or an extension of IO; unless you want to get into some rather ugly messing around with `unsafePerformIO'. Cheers, Manuel

1 0

Clean ObjectIO
by Krasimir Angelov 27 Sep '01

27 Sep '01

I have extended version of haskellised ObjectIO library. She is based on original "Port of the Clean Object I/O library to Haskell", but now support many other thinks: ComboBox, CheckControl, RadioControl, Slider ... Draw monad and initial support of windows Is there any interested about this __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

1 0

Re: RFC: GUI Library Task Force
by Manuel M. T. Chakravarty 26 Sep '01

26 Sep '01

[redirected to gui(a)haskell.org] Juan Carlos Arévalo Baeza <jcab(a)roningames.com> wrote, > On Tue, 25 Sep 2001 17:41:06 +1000, Manuel M. T. Chakravarty wrote: > > >> Many applications where GUIs are used require a canvas/scribble field > >> with the following basic functionality: > >> > >> - set a point in a particular color; if speed is an issue, > >> mapping a 2D-array content to the canvas would be useful > > > >Sure - such functionality needs to be included. However, a > >canvas widget is just one among many. > > IMHO, the main interest on having this kind of > functionality singled out is that this allows any other > drawing primitive to be implemented in a generic > way. You wouldn't have fast implementations, but this > will allow complete implementations of the drawing > portion of the GUI to be done real quickly, and it > would also provide a reference implementation for all > the basic drawing primitives. Any implementation that > uses hardware acceleration or that defers rendering of > primitives to the operating system can then be checked > against that reference implementation. Facilities for extension is certainly a good thing to have. And it doesn't necessarily mean that such extensions need to be slow. The architecture of GTK+ (at least, the C API) is a good example of how the real implementation of all widgets can actually be based on one generic mechanism. It would be very interesting to see how far this approach could be transferred to Haskell. Manuel

1 0

Re: GUI Library Task Force
by Andy Gill 26 Sep '01

26 Sep '01

"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. So you want various IO operations, that act not only in the IO monad, but in other monads also? Perhaps something like putStrLn :: (MonadIO io) => String -> io () Then writing you IO operations inside your GUI becomes trivial. Lets push this a bit with an implementation. -- a way of tunneling into the IO Monad class (Monad m) => MonadIO m where runIO :: IO v -> m v -- and the "default" IO monad. instance MonadIO IO where runIO m = m -- a sample GUI newtype GUI a = GUI { unGUI :: IO a } -- wibble instance Monad GUI where return a = GUI (return a) (GUI m) >>= k = GUI (m >>= \ r -> unGUI (k r)) -- how the GUI tunnels instance MonadIO GUI where runIO m = GUI m -- and an implementation of putStrLn putStrLn :: (MonadIO io) => String -> io () putStrLn str = runIO (Prelude.putStrLn str) -- You need to import the Prelude hiding putStrLn, -- the import putStrLn qualified, but it should be -- possible to develop a module that contains -- your favorite IO monadic things, behind which -- this magic is hidden. (I'm not arguing for/against the Clean GUI, but one of your points of reasoning). -- Andy Gill Galois Connections

2 1

RE: GUI Library Task Force
by Simon Peyton-Jones 25 Sep '01

25 Sep '01

[replying to the GUI list] I don't have a strong opinion myself -- I'm just advocating a little careful study, since Clean has a lot of experience. It might be worth asking Peter Aachten for his advice/ideas. Invite him to join the list? | * 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. Definitely agree to keep them separate. But I do think the GUI API should perhaps conceal whether it's using IORefs or MVars, since in a concurrent system one will certainly want to use the latter. | * 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. This is indeed the most significant feature. It has the merit that there is a data structure that acts as a description of the GUI, which has some conceptual clarity, for me anyway. Instead of building up a model in your head, there it is written down (you can presumably even print it out). Not so good when the GUI shape is changing -- I wonder how Clean does that. Anyway, all I'm not pressing to adopt that model; merely to think about it. There is lots more tutorial material about the design than our short paper. Simon

2 1