[Haskell-cafe] The Good, the Bad and the GUI

[Alberto G. Corona]

2014-08-12 1:21 GMT+02:00 Tikhon Jelvis <tikhon at jelv.is>:

> For the original question: take a look at functional reactive programming
> (FRP). It takes a slightly different approach to the whole GUI problem,
> but, I've found, obviates some of your issues.
>
> You can quickly play around with FRP and HTML UIs by using threepenny-gui
> and Reactive Banana. The former is a simple UI framework that lets you
> create and interact with HTML in Haskell, and the latter in a nice library
> for FRP. They work well together:
>
> http://apfelmus.nfshost.com/blog/2013/08/02-reactive-banana-threepenny.html
>
> There's a nice tutorial about FRP and Reactive Banana you can read on the
> Haskell Wiki. I haven't had the chance to go through it myself, but it
> looks promising.
>
> http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana
>
> If you're wondering about Haskell and UIs, I think FRP is the best place
> to look—it provides the most pleasant semantics for programming UIs that
> I've come across, although most of the libraries are still a bit
> experimental. (Implementing the exact semantics we'd like turned out to be
> very difficult!)
>
> > The reactive solutions complicates the problem rather than to simplify
> it. That means that they are not the correct paradigm.
>
> That's a very hasty, superficial way to dismiss a whole paradigm!
>

Yes!

 I was just trying to be a bit provoking. Sorry.

The objections about the use of  current FRP models for GUIs are here:

http://homepages.cwi.nl/~ploeg/papers/monfrp.pdf

and here:

https://www.fpcomplete.com/user/agocorona/a-monad-for-reactive-programming-part-1

Allthough FRP is too wide. Monadic FRP is more appropriate for GUIs for the
same reasons.  hplayground uses monadic FRP + formlets


> FRP libraries have proven *difficult to implement*, but this does not mean
> they somehow "complicate the problem". The real insight with FRP is
> developing a nice semantics *for the end user* and making it simpler to
> work with the libraries, at the expense of a more complex implementation.
> It's a parallel to functional programming at large: we're willing to trade
> complexity in GHC in return for a nicer high-level programming environment.
>
> Formlets are an interesting concept, but they seem to be significantly
> more narrow than FRP. How do formlets address continuous things like
> animations or mouse movement?
>
> Also, a lot of the examples (at least on the Haskell wiki[1]) seem pretty
> amenable to FRP. How is
>
>     chooseBool :: Form Bool
>     chooseBool = enumRadio [(True, "Yes"), (False, "No")] True
>
> significantly different from just providing a Behavior Bool in the spirit
> of FRP?
>
>
> On Mon, Aug 11, 2014 at 3:57 PM, Wojtek Narczyński <wojtek at power.com.pl>
> wrote:
>
>>
>> On 12.08.2014 00:53, Alberto G. Corona wrote:
>>
>>> I think that the GUI people hace to embrace the formlet concept, used in
>>> HTML interfaces sooner better than later. The GUI development has lost the
>>> train by trying to interface C libraries that are decades old. The reactive
>>> solutions complicates the problem rather than to simplify it. That means
>>> that they are not the correct paradigm.
>>>
>>>  I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
>> explicitly upfront.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/f0c8644b/attachment-0001.html>