[Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire

[Peter Althainz]

Hi Heinrich, Hi Ertugrul

thanks for all your comments so far. In last e-mail, you wrote:

Heinrich Apfelmus <apfelmus at quantentunnel.de> wrote:
> In the case of HGamer3D, the sink combinator would replace the need to
> declare a final "wire which runs all the wires at each step".  It
> feels a bit weird to me to have wires like guiSetPropW that perform
> side effects, i.e. where it makes a different whether you observe
> their results or not. That's a complexity where I feel that something
> "has been swept under the rug".

In particular imperative wires like guiSetPropW (or anything for which
*set*  is a sensible name) are simply wrong.  A widget, e.g. a button,
should look like this:

     type MyWire    = WireM (Reader MyConfig)
     type MyEvent a = MyWire a a

     button :: MyEvent Button


=>

A short explanation on the guiSetPropW wire:

The guiSetPropW can be considered as being part of the GUI binding actually. It is
in the public Api to overcome the limitation of not having all properties as single wires coded.
Anyhow, if you want to act on something in the GUI (for example make a window visible or not)
you will probably need something with a side effect. That is, where
the guiSetPropW is used in the examples. But it is a little bit low level, the
higher level wires look more nicer:

for example, the button wire creation acutally looks like that:

buttonW:: GUIElement -> GameWire a a

with the button wire having the type of: GameWire a a
It is a pure event wire, which gets fired, when the button is pressed.


the "label" wire creation

staticTextW :: GUIElement -> GameWire String String

with the labe wire having the type of: GameWire String String


the "editbox" wire creation:

editBoxW :: GUIElement -> (GameWire a String, GameWire String String)

creates two wires, one for getting notified on changes of the element:
type: GameWire a String

and one for setting a new value to the string:
type: GameWire String String

Here, I would be interested in your view. Of course you can make one wire out of it, but this has different
consequences:

- how to check for a change in the widget, if the wire is not executed, because no input value occur?
- usually you need the output of the wire in different places of your final network where the input wire is needed, if you have only one wire this might be cumbersome, to code in combining the final network
- and: yes, there has been also something swept under the rug here, because since both wires refer to the same GUI element, there is the same GUI element used inside, which is a reference. Actually this is somthing more OO/Scala like then Haskell but it works fine for me so far, since it does overcome the limitations of the points above.

BR
Peter