[Haskell] Arrows GUI Library Based on GTK+

[Kevin Atkinson]

On Sat, 19 Mar 2005 ross at soi.city.ac.uk wrote:

> On Fri, Mar 18, 2005 at 07:18:29PM -0700, Kevin Atkinson wrote:
> > What follows is my first attempt of using Arrows to create a GUI Library 
> > based on GTK+.  It uses many ideas from Fruit (http://haskell.org/fruit/). 
> > However it is based on discrete events rather than a continuous signal. 
> > The interface is only updated during an Event. It also ideas from Fudgets 
> > (http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/), some of which 
> > were also used by Fruit.  
> 
> The implementation of Fruit is also based on discrete events,
> though the abstract description talks about continuous signals.

In FG there is no notation of continuous time.  Something only happens 
during a user event.  In Fruit the each Arrow revives input continuously 
(conceptually, in reality it us during fixed intervals).  In the paper they 
mention that they tried to make into the formal but ran into serious
problems with due to the way they implemented things.  I am not sure if it 
is fundamental to the fire

> 
> Your module uses the arrow interface, but it's actually equivalent to
> monads.  

It is?  Than what would "app" look like?

> I don't know if this is the source of the multiple traversals,
> but you may wish to experiment with synchronous stream arrows like
> Automaton transformer in the experimental arrow transformer library
> linked from the arrows page, or an asynchronous Fudgets-like arrow
> (see John's original paper).

I will get back to you.  I can sort of see how it is Monad (but won't be 
convinced until I see an "app" implementation).  Has anyone tried to make 
Fudgets an instance of the Arrow class?

> Some more minor suggestions:

> - how about: data Event a = NoEvent | Event a

And what would "a" be?  For Now I only have one event.  I do need a more 
extensible Event system.

> - you don't really need mkAFunDef in AbstractFunction, and indeed you
>   don't need AbstractFunction either -- you could just use Arrow, of
>   which both (->) and FG are already instances.

But than can I make a function like "tag" which can either be used as an 
arrow or a function.  Ie:
  a <- tag "a" <<< button [] -< def
  b <- tag "b" <<< button [] -< def
  let e = a >< b
  ...
OR
  a <- button [] -< def
  b <- button [] -< def
  let e = tag "a" a >< tag "b" b
  ...

> - you could make FG, FG', EntryP newtypes instead of using the !
>   annotation.

Yes your right.

> - I'd suggest making Container a newtype, so it could have an Arrow
>   instance (it would be a reader arrow).  Then hbox and vbox could be
>   used as arrow operators/combinators.

I will look into it.  I am still trying to fully understand Arrows.  Which 
is maybe why I may of inadvertently made a monad.

-- 
http://kevin.atkinson.dhs.org