Heinrich Apfelmus <[email protected]> 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".
I did not review the interface of HGamer3D, mostly because it's
Windows-only. But I'd like to point out that you would prefer a non-IO
monad for wires. In most cases I would recommend a monad for which (>>)
is commutative like a reader and/or a commutative writer. The purpose
of the underlying monad is to allow some event wires to be written more
cleanly. Without the monad:
keyPressed :: (Monad m, Monoid e)
=> SDL.Keysym
-> Wire e m SDL.Event SDL.Event
With the monad:
keyPressed :: (SDLMonad m, Monoid e)
=> SDL.Keysym
-> Wire e m a a
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
This wire takes a button configuration describing the current state of
the button. Given an IsString Button instance and OverloadedStrings a
GUI with a button could look like this:
numberField =
label >>>
textField "" <|> errorLabel . "Please enter a valid number"
dialog = proc _ -> do
n1 <- numberField -< "Number 1"
n2 <- numberField -< "Number 2"
let s = n1 + n2 :: Integer
label -< "Sum: " ++ show s
button -< "Okay"
id -< s
As most event wires the button wire acts like identity when the button
is pressed, so it would return back the button configuration. I hope
this sheds some light onto what GUI code in Netwire /should/ (in fact
/will/) look like.
Greets,
Ertugrul
--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
