Re: [Gtk2hs-users] GTK programming based on arrows

[Axel S. <A....@ke...>]

Michal,

On Thu, 2005-08-04 at 09:20 +0200, Michal Palka wrote:
> Hello,
> 
> In one of my last emails I complained about having to track state
> explicitly in a program with GUI. Recently I came across a toolkit that
> is based on signal transformers and imo deals with encapsulating the
> state nicely. That GUI (Fruit) is a theoretical work and relies entirely
> on signal transformations i.e. no imperative programming is possible
> there.
> 
> I tried to implement some substitute of an arrow-based GUI for Gtk2hs.
> My goal was to write a practical supplement which could be used along
> with the imperative interface of Gtk2hs and which would allow
> programmers to use haskell arrow notation.

We would very much welcome such an interface on top of our low-level
library! If you come up with something consistent and practical, then we
will certainly be happy to distribute your interface with Gtk2Hs.

> Please look at the attached source containing my (unfinished) attempt to
> create such an interface and sample code using it. I have defined Signal
> arrow (yes, I know about the name clash;)), which will be used for
> automatically updating attributes based on values of other attributes.
> For instance, it will be possible to place a text contained in an entry
> as a label on a button using this code:
> 
> connectSignal (attrSource entry entryText) button buttonLabel
> 
> Furthermore, the button label would be updated as soon as the text in
> the entry changes.

Looks interesting. I'm afraid I have no experience with Fruit nor Arrows
in general. I have worked with Fudgets which are boxes with input and
output wires which you connect with combinators. They were rather
inflexible in practise, in the sense that you could not attach any input
wire to any output wire, but only certain combinations. Your approach
seems more general.

> Signal arrow contains an IO a computation which is used to extract final
> value from it, based on values of attributes that it depends on. It's
> really an IO monad embedded in Signal arrow as all references to
> attributes depended on are contained in the arrow.

Ok, I think I understand this. So what this implements a "pull" or
polling interface. 

[...]

> The problem I'm facing now is how to implement notifying signal
> listeners of attribute changes. I will probably have to make attributes
> carry an IORef containing a list of listeners. Unfortunately, all
> attributes-related functions would then have to be changed to IO
> actions.

Ok, so this would be a "push" interface, like the Gtk signals. Regarding
to the IORef problem: Do you not return a new Signal once you've added a
new listener? If so, could this new Signal not contain store the IO
action that you passed in?

If you lift the attribute-related functions to the IO monad, would there
be a straight-forward way to modify one attribute based on the input of
two or more other inputs?

> Also, there is not yet any way to make Signal arrow stateful, but I
> think it will be straightforward to extend it that way.

Yes, that's certainly necessary :-). Although I'm having trouble enough
understanding the Arrow stuff in your source code, I'd like to see an
example where you have a state attribute, two input signals that modify
it and two output signals that propagate the value to some destination.
Such an example would make it clearer to me as to how practical your
suggestion is. Manuel Chakravaty implemented an interface he called
iHaskell, which has some shortcomings which I can't recall from the top
of my head. It might be interesting to see what he came up with.

Thanks for your ideas,
Axel.