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

[Conal Elliott]

Thanks much for these thoughtful questions and implementation perspectives.

Internally, Phooey works very like an imperative GUI program, pushing
computations when inputs change.  So I'd expect it to have pretty much the
same performance properties.   As you mentioned, lazy evaluation can play a
role in making evaluation subtler.  The laziness probably doesn't work out
as nicely as we'd like, however.  On an input change, a new output value is
constructed lazily, but then a call is to the underlying low-level gui
toolkit (eg wxWidgets), which will cause the output value to be fully
evaluated.  I'm assuming that wxHaskell doesn't do clever postponing &
collapsing of output calls to wxWidgets.  But perhaps it could do so, or
Phooey could do so on top of wxHaskell.  Probably a good idea, and it
certainly hadn't occurred to me.

The paper I'm working is partly about Phooey the interface, but more about
systematically refactoring the imperative programming style into the Phooey
interface and its implementation.  This derivation is why I believe that
Phooey is operationally very like the imperative approach (while presenting
a radically different interface).  It could be that Phooey internally
operates like a naive imperative GUI program, of the sort I tend to write.

Thanks also for the suggested example and discussion of requirements of the
underlying imperative toolkit.

Best regards, - Conal

On 12/12/06, Brian Hulley <brianh at metamilk.com> wrote:
>
> Brian Hulley wrote:
> > Conal Elliott wrote:
> >
> >> GUIs are usually programmed in an "unnatural" style, in that ...
> >
> > Also, suppose you have a gui consisting of an edit widget such that
> > when the user types something it gets lexed, parsed, and fontified as
> > a Haskell program, ie from the user's point of view the widget
> > maintains a syntax highlighted view of the code which is
> > "continuously" updated. Would your system do the lexing/parsing for
> > every key that was pressed or only once, when the widget needs to be
> > re-rendered (a typical gui for Windows would only propagate changes
> > and re-draw the gui (ie lex/parse/fontify) when there are no event
> > messages pending)?
>
> Thinking about this more, a better example would be a gui with 2 widgets:
> an
> edit widget to type in code and a list widget which displays a list of top
> level functions defined in that code. (The code could be Haskell or some
> simple toy language.)
> Then the question becomes: how to set things up such that the code in the
> edit widget is only parsed when the list widget (and/or edit widget) is
> asked to render it's contents rather than every time the user presses a
> key.
> I think perhaps the problem would be solved by the edit widget passing a
> lazy parse tree (ie an expression evaluating to the parse tree) to the
> list
> widget.
>
> But an interesting thing is if you compare this to imperative guis, in the
> functional gui each widget passes lazy expressions eagerly whereas in
> imperative guis each widget passes eagerly evaluated expressions lazily ie
> functional is "push messages" whereas imperative is "pull changes when I'm
> asked to pick or render something etc and I'm dirty". (Have I got this
> wrong?)
>
> I imagine that the overhead of eager passing in the functional gui is a
> small price to pay for the ease of using a functional gui, since the
> important thing is that in both guis, the hard work of parsing the code in
> the edit buffer would only be done on demand, unless I'm much mistaken.
>
> If you're still thinking of examples for your paper it would also be
> really
> great to see how you'd create a widget that displays the result of another
> process (eg a window that displays the output as ghc compiles a program)
> or
> some other example of how to use the IO monad inside a widget for those
> unfamiliar with combining arrows with monads.
>
> It would also be useful to know more about the relationship between the
> functional gui and WxWidgets to see what characteristics an imperative gui
> toolkit must have in order to be usable with it. (Like the extremely
> useful
> discussion of low level details in the Fudgets thesis.)
>
> Best regards, Brian.
> --
> http://www.metamilk.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20061212/294854c3/attachment.htm