[Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haskell

[Conal Elliott]

Hi Antony,

Phooey is much simpler and less ambitious than Yampa & Fruit.  Semantically,
it's the same arrow, namely functions from input flows to output flows.
Internally, it does simple data-driven evaluation.  No "events" &
"switching" in the FRP sense.  I didn't try to address dynamic collections.
Pretty simple stuff.

As for non-rectilinear layout, I think I could wrap up Phooey-style anything
that the underlying library's layout mechanism provides. Layout in wxHaskell
is particularly nice to work with, as they're already functional.

The interest driving me to release & write up Phooey is as I mentioned in my
reply to Brian.  I wanted to understand and clearly express a pathway of
transformation (refactoring) between the imperative style and a simple
functional style.  That transformation is what the paper-in-progress is
about.

Regards,   - Conal

On 12/12/06, Antony Courtney <antony.courtney at gmail.com> wrote:
>
> Hi Conal,
>
> Looks like an interesting system.
>
> A few questions:
>    - What is the underlying Arrow here, and how does it differ from
> Yampa?  (And the obvious follow-on: If they are similar, why not just use
> Yampa?)
>    - How will your layout model deal with layouts that aren't rectilinear?
>    - Do you support events or switching (in the FRP sense)?
>    - How do you plan to deal with dynamic collections (opening/closing
> new windows at runtime, or adding/removing widgets from a running
> GUI)?  IMO, this is the biggest challenge to presenting a purely
> functional API but using a standard GUI toolkit for the underlying widget
> set.
>
> Regards,
>
>     -Antony
>
> On 12/12/06, Conal Elliott <conal at conal.net> wrote:
>
> > Announcing Phooey <http://conal.net/phooey>, a functional UI library for
> > Haskell.
> >
> > GUIs are usually programmed in an "unnatural" style, in that
> > implementation dependencies are inverted, relative to logical dependencies.
> > This reversal results directly from the imperative orientation of most GUI
> > libraries. While outputs depend on inputs from a user and semantic point of
> > view, the imperative approach imposes an implementation dependence of inputs
> > on outputs.
> >
> > Phooey ("*Ph*unctional *oo*s*e*r *y*nterfaces") retains the functional
> > style, in which outputs are expressed in terms of inputs. In addition,
> > Phooey supports dynamic input bounds, flexible layout, and
> > mutually-referential widgets.
> >
> > As an example of Phooey's style, below is a simple shopping list GUI.
> > The *total* displayed at the bottom of the window always shows the sum
> > of the values of the *apples* and *bananas* input sliders. When a user
> > changes the inputs, the output updates accordingly.
> >
> >
> > Phooey is structured as an arrow, and this example uses arrow notation.
> > The code:
> >
> >     ui1 :: UI () ()
> >     ui1 = title "Shopping List" $
> >
> >           proc () -> do
> >             a <- title "apples"  (islider 3) -< (0,10)
> >             b <- title "bananas" (islider 7) -< (0,10)
> >
> >             title "total" showDisplay        -< a+b
> >
> >
> > I am working on a paper about Phooey. For now, please see the Haddock
> > documentation <http://darcs.haskell.org/packages/phooey/doc> (which
> > includes more examples), and try the code via
> >
> > darcs get http://darcs.haskell.org/packages/phooey --partial
> >
> >
> > Directions for building are in the README<http://darcs.haskell.org/packages/phooey/README>file. Distribution tarballs are
> > here <http://darcs.haskell.org/packages/phooey/dist>.
> >
> > Comments and collaboration are very welcome!
> >
> > Cheers,
> >
> >        - Conal
> >
> > P.S. I'm very grateful for Don Stewart's recent pointers on how to
> > create & release Haskell projects.
> >
> > _______________________________________________
> > Haskell mailing list
> > Haskell at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20061212/672f0dd0/attachment.htm