当前功能反应式编程实现的状态是什么?

mni*_*ish 87 erlang haskell functional-programming reactive-programming

我正在尝试在Haskell中可视化一些简单的自动物理系统(例如摆锤,机器人手臂等).通常这些系统可以用类似的方程来描述

df/dt = c*f(t) + u(t)

其中,u(t)代表了某种"智能控制"的.这些系统看起来非常适合功能反应式编程范例.

因此,我通过保罗·哈达克抓起书"表达的哈斯克尔学校",并发现,领域特定语言"FAL"(功能动画语言)提出有实际工作相当pleasently我简单的玩具系统(虽然某些功能,尤其是integrate,似乎有点懒得有效使用,但很容易修复).

我的问题是,对于今天更先进甚至实际的应用,更成熟,最新,维护良好,性能优化的替代方案是什么?

这个wiki页面列出了Haskell的几个选项,但我不清楚以下几个方面:

  1. "反应"的状态,来自Conal Eliott的项目(据我所知)是这种编程范式的发明者之一,看起来有点陈旧.我喜欢他的代码,但也许我应该尝试其他更新的替代品?在语法/性能/运行时稳定性方面,它们之间的主要区别是什么?

  2. 引用2011年的一项调查,第6节," ...... FRP实施仍然没有足够的效率或足够可预测的性能,无法在需要延迟保证的领域中有效使用...... ".Alghough调查提出了一些有趣的可能的优化,鉴于FRP是有超过15年,我得到的印象是,这个性能问题可能会是一件非常,甚至本来就很难在几年内至少解决.这是真的?

  3. 该调查的同一位作者在他的博客中谈到了"时间泄漏" .问题是FRP独有的,还是我们在用纯粹的非严格语言编程时通常会遇到的问题?您是否曾经发现,如果性能不够,那么随着时间的推移稳定基于FRP的系统就太难了?

  4. 这还是一个研究水平的项目吗?人们喜欢工厂工程师,机器人工程师,金融工程师等实际使用它们(用适合他们需要的各种语言)吗?

虽然我个人更喜欢Haskell实现,但我愿意接受其他建议.例如,拥有一个Erlang实现会特别有趣 - 那么拥有一个智能的,自适应的,自学的服务器进程就很容易了!

小智 80

现在主要有两个实用的Haskell库用于功能反应式编程.两者都由单个人维护,但也接收来自其他Haskell程序员的代码贡献:

  • Netwire专注于效率,灵活性和可预测性.它有自己的事件范例,可用于传统FRP不起作用的领域,包括网络服务和复杂的模拟.风格:适用和/或箭头化.最初的作者和维护者:ErtugrulSöylemez(这是我).

  • 反应性香蕉建立在传统的FRP范式之上.虽然它是实用的,它也可作为经典FRP研究的基础.它主要关注用户界面,并且有一个现成的wx接口.风格:适用.最初的作者和维护者:Heinrich Apfelmus.

您应该尝试这两种方法,但根据您的应用,您可能会发现其中一种更适合.

对于游戏,网络,机器人控制和模拟,你会发现Netwire很有用.它配备了适用于这些应用的现成电线,包括各种有用的差异,积分和许多用于透明事件处理的功能.有关教程,请访问Control.Wire我链接的页面上的模块文档.

对于图形用户界面,目前您最好的选择是reactive-banana.它已经有一个wx接口(作为一个单独的库reactive-banana-wx),Heinrich在这个上下文中包含很多关于FRP的博客,包括代码示例.

回答您的其他问题:FRP不适合您需要实时可预测性的情况.这很大程度上归功于Haskell,但遗憾的是FRP很难在低级语言中实现.一旦Haskell本身变为实时就绪,FRP也将实现这一目标.从概念上讲,Netwire已准备好用于实时应用程序.

时间泄漏不再是一个问题,因为它们主要与monadic框架有关.实用的FRP实现根本不提供monadic接口.Yampa已经启动了这个,Netwire和反应香蕉都是基于此.

我知道目前没有使用FRP的商业或其他大型项目.图书馆准备就绪,但我认为人们还没有.

  • 值得注意的是,最近用Haskell编写的独立游戏([Nikki and the Robots](http://joyridelabs.de/game/))决定_not_使用FRP. (3认同)

Joh*_*n L 23

虽然已有一些好的答案,但我将尝试回答您的具体问题.

  1. 由于时间泄漏问题,反应不适用于严肃的项目.(见#3).当前具有最相似设计的库是反应性香蕉,它是以反应性为灵感而开发的,并与Conal Elliott进行了讨论.

  2. 虽然Haskell本身不适合硬实时应用程序,但在某些情况下可以将Haskell用于软实时应用程序.我不熟悉目前的研究,但我不相信这是一个不可逾越的问题.我怀疑像Yampa这样的系统或像Atom这样的代码生成系统可能是解决这个问题的最佳方法.

  3. "时间泄漏"是可切换FRP特有的问题.当系统无法释放旧对象时会发生泄漏,因为如果在将来的某个时刻发生切换,可能需要它们.除了内存泄漏(可能非常严重)之外,另一个后果是,当切换发生时,系统必须暂停,同时遍历旧对象链以生成当前状态.

不可切换的frp库(例如Yampa和旧版本的反应性香蕉)不会遭受时间泄漏.可切换的frp库通常采用两种方案中的一种:要么它们具有创建FRP值的特殊"创建单元",要么它们使用"老化"类型参数来限制可以发生切换的上下文. elerea(可能还有netwire?)使用前者,而最近的反应性香蕉和葡萄柚使用后者.

通过"可切换的frp",我的意思是实现Conal的功能switcher :: Behavior a -> Event (Behavior a) -> Behavior a或相同的语义.这意味着网络的形状可以在运行时动态切换.

这与@ ertes关于monadic接口的声明并没有真正的矛盾:事实证明,为一个Monad实例提供一个实例Event可能会造成时间泄漏,并且使用上述任何一种方法都不再可能定义等效的Monad实例.

最后,虽然FRP还有很多工作要做,但我认为一些较新的平台(reactive-banana,elerea,netwire)足够稳定和成熟,你可以从中构建可靠的代码.但是你可能需要花费大量时间来学习这些细节,以便了解如何获得良好的表现.

  • 不要忘记[反应香蕉的香蕉 - 克星](http://apfelmus.nfshost.com/blog/2012/08/26-frp-banana-0-7.html):[钠](http:/ /hackage.haskell.org/package/sodium). (3认同)
  • 关于基于箭头的库(Yampa,netwire),它们也可以切换.原因是箭头内置了老化,你实际上无法摆脱它.(作为流变换器,箭头与输入流的开始时间无关.) (2认同)
  • @DanBurton谢谢,我试图记住这个名字是不成功的.我同意钠应该被认为是现代的FRP库,尽管它不像反应性香蕉那样受欢迎. (2认同)

Hen*_*rik 20

我要列出Mono和.Net空间中的几个项目,以及我不久前发现的Haskell空间中的一个项目.我将从Haskell开始.

榆树 - 链接

根据其网站描述:

Elm旨在使前端Web开发更加愉快.它引入了一种新的GUI编程方法,可以纠正HTML,CSS和JavaScript的系统性问题.Elm允许您快速轻松地使用可视化布局,使用画布,管理复杂的用户输入,以及逃避回调地狱.

它有自己的FRP变体.从玩它的例子看起来很成熟.

反应性扩展 - 链接

首页描述:

Reactive Extensions(Rx)是一个库,用于使用可观察序列和LINQ样式查询运算符组合异步和基于事件的程序.使用Rx,开发人员使用Observables表示异步数据流,使用LINQ运算符查询异步数据流,并使用Scheduler参数化异步数据流中的并发性.简单地说,Rx = Observables + LINQ + Schedulers.

Reactive Extensions来自MSFT,并实现了许多简化处理事件的优秀运算符.它是开源的在几天前.它非常成熟并用于生产; 在我看来,它将是Windows 8 API比TPL库提供的更好的API; 因为可观察对象既可以是热的也可以是冷的,并且可以重试/合并等,而任务总是代表热的或完成的计算,无论是运行,故障还是完成.

我使用Rx编写服务器端代码用于异步,但我必须承认在C#中功能写入可能有点烦人.F#有几个包装器,但很难跟踪API开发,因为该组相对封闭,并且不像其他项目那样由MSFT推广.

它的开源采用了IL-to-JS编译器的开源,因此它可能适用于JavaScript或Elm.

您可以使用消息代理(如RabbitMQ和SocksJS)非常好地绑定F#/ C#/ JS/Haskell.

Bling UI工具包 - 链接

首页描述:

Bling是一个基于C#的库,可以在Microsoft的WPF/.NET上轻松编程图像,动画,交互和可视化.Bling面向设计技术专家,即有时编程的设计师,以帮助快速构建丰富的UI设计理念.学生,艺术家,研究人员和业余爱好者也会发现Bling可以作为快速表达想法或可视化的工具.Bling的API和构造针对丢弃代码的快速编程进行了优化,而不是仔细编程生产代码.

免费的LtU文章.

我已经测试了这个,但没有用它来进行客户端项目.它看起来很棒,有很好的C#运算符重载,形成值之间的绑定.它使用WPF/SL /(WinRT)中的依赖项属性作为事件源.它的3D动画在合理的硬件上运行良好.如果我最终得到一个需要可视化的项目,我会用它; 可能将其移植到Windows 8.

ReactiveUI - 链接

曾在MSFT工作的Paul Betts现在在Github编写了这个框架.我已经非常广泛地使用它并且喜欢这个模型.它比Blink(从使用Rx及其抽象的本质)更加分离 - 使用它更容易单元测试代码.用于Windows的github git客户端就是用这个来编写的.

评论

对于大多数性能要求苛刻的应用,反应模型的性能足够高.如果您正在考虑硬实时,我会打赌大多数GC语言都有问题.Rx,ReactiveUI创建了一些需要GCed的小对象,因为这就是如何创建/处理订阅以及在回调的被动"monad"中进行中间值.一般来说.Net上我更喜欢基于任务的编程的反应式编程,因为回调是静态的(在编译时已知,没有分配),而任务是动态分配的(未知,所有调用都需要一个实例,垃圾创建) - 并且lambdas编译成编译器生成的类.

显然C#和F#是严格评估的,因此时间泄漏不是问题.JS也是如此.但它可能是可重放或缓存的可观察量的问题.