我最近发现了FP错误(试图学习Haskell)，到目前为止，我对我所看到的(一流函数、惰性求值和所有其他好东西)印象深刻。我还不是专家，但我已经开始发现对基本算法进行“功能性”推理比命令式推理更容易(而且我很难回到我必须回到的地方)。
The one area where current FP seems to fall flat, however, is GUI programming. The Haskell approach seems to be to just wrap imperative GUI toolkits (such as GTK+ or wxWidgets) and to use "do" blocks to simulate an imperative style. I haven't used F#, but my understanding is that it does something similar using OOP with .NET classes. Obviously, there's a good reason for this--current GUI programming is all about IO and side effects, so purely functional programming isn't possible with most current frameworks.
My question is, is it possible to have a functional approach to GUI programming? I'm having trouble imagining what this would look like in practice. Does anyone know of any frameworks, experimental or otherwise, that try this sort of thing (or even any frameworks that are designed from the ground up for a functional language)? Or is the solution to just use a hybrid approach, with OOP for the GUI parts and FP for the logic? (I'm just asking out of curiosity--I'd love to think that FP is "the future," but GUI programming seems like a pretty large hole to fill.)
实际上，我想说函数式编程(f#)对于用户界面编程来说是比c#更好的工具。你只需要稍微换个角度思考问题。
我在我的函数式编程书的第16章中讨论了这个主题，但是有一个免费的节选，它展示了(恕我直言)你可以在f#中使用的最有趣的模式。假设你想要实现矩形的绘制(用户按下按钮，移动鼠标并释放按钮)。在f#中，你可以这样写:
let rec drawingLoop(clr, from) = async {
// Wait for the first MouseMove occurrence
let! move = Async.AwaitObservable(form.MouseMove)
if (move.Button &&& MouseButtons.Left) = MouseButtons.Left then
// Refresh the window & continue looping
drawRectangle(clr, from, (move.X, move.Y))
return! drawingLoop(clr, from)
else
// Return the end position of rectangle
return (move.X, move.Y) }
let waitingLoop() = async {
while true do
// Wait until the user starts drawing next rectangle
let! down = Async.AwaitObservable(form.MouseDown)
let downPos = (down.X, down.Y)
if (down.Button &&& MouseButtons.Left) = MouseButtons.Left then
// Wait for the end point of the rectangle
let! upPos = drawingLoop(Color.IndianRed, downPos)
do printfn "Drawn rectangle (%A, %A)" downPos upPos }
这是一种非常必要的方法(在通常实用的f#风格中)，但它避免使用可变状态来存储绘图的当前状态和存储初始位置。它可以做得更有功能，我写了一个库，作为我硕士论文的一部分，应该在几天后可以在我的博客上看到。
函数式响应式编程是一种更函数化的方法，但我发现它有点难以使用，因为它依赖于相当高级的Haskell特性(比如箭头)。然而，在大量的情况下，它是非常优雅的。它的局限性在于您不能轻松地对状态机进行编码(这是响应式程序的有用心理模型)。使用上面的f#技术，这是非常容易的。
Haskell方法似乎只是包装命令式GUI工具包(如GTK+或wxWidgets)，并使用“do”块来模拟命令式样式
这并不是真正的“Haskell方法”——这只是通过命令式接口最直接地绑定到命令式GUI工具包的方法。Haskell恰好有相当突出的绑定。
有几种比较成熟的，或者更具实验性的纯函数式/声明式gui方法，主要是在Haskell中，主要使用函数式响应式编程。
一些例子是:
reflex-platform, https://github.com/reflex-frp/reflex-platform
葡萄柚,http://hackage.haskell.org/package/grapefruit-ui-gtk
无功,http://hackage.haskell.org/package/reactive-glut
wxFruit, http://hackage.haskell.org/package/wxFruit
reactive-banana, http://hackage.haskell.org/package/reactive-banana
对于那些不熟悉Haskell、Flapjax、http://www.flapjax-lang.org/的人来说，http://www.flapjax-lang.org/是一个基于JavaScript的函数式响应式编程的实现。
Windows Presentation Foundation证明了函数式方法非常适合GUI编程。它有许多功能方面，“好的”WPF代码(搜索MVVM模式)强调功能方法而不是命令式方法。我可以勇敢地宣称WPF是现实世界中最成功的功能GUI工具包:-)
WPF在XAML中描述了用户界面(尽管你也可以把它重写成函数式的c#或f#)，所以要创建一些用户界面，你可以这样写:
<!-- Declarative user interface in WPF and XAML -->
<Canvas Background="Black">
<Ellipse x:Name="greenEllipse" Width="75" Height="75"
Canvas.Left="0" Canvas.Top="0" Fill="LightGreen" />
</Canvas>
此外，WPF还允许你使用另一组声明性标记来声明性地描述动画和对事件的反应(同样，同样的事情也可以写成c# / f#代码):
<DoubleAnimation
Storyboard.TargetName="greenEllipse"
Storyboard.TargetProperty="(Canvas.Left)"
From="0.0" To="100.0" Duration="0:0:5" />
事实上，我认为WPF与Haskell的FRP有很多共同之处(尽管我相信WPF的设计者并不知道FRP，这有点不幸——如果你使用函数的观点，WPF有时会感觉有点奇怪和不清楚)。
