功能性过剩？答案

【问题标题】：Functional GLUT?功能性过剩？
【发布时间】：2009-08-26 09:21:25
【问题描述】：

我通过限制自己不使用 set! 来学习 Gambit-C Scheme 中的一些函数式编程。我认为使用这种环境编写一个小 OpenGL 游戏可能会很有趣，这似乎很适合游戏开发。

但是，在使用 OpenGL 和 GLUT 时，似乎很难坚持函数式风格并避免全局状态。我认为这本身并不是游戏编程的基本限制，但基于回调的 API（如 GLUT）似乎不适用于函数式编程。

例如，我试图将世界想象成一个不断变化的状态向量流，它是时间步长和用户输入事件的交错列表的函数。这个想法似乎还可以，但是对于异步编程来说似乎并不容易。例如，我必须为 GLUT 的显示函数注册一个回调，它应该能够以某种方式访问此流中的“当前”项目。同时，没有什么可以通过从中获取来推动流向前。

理想情况下，我需要某种“外部”GLUT 的东西，这是一个主要功能，它以某种方式依赖于（可能是单子的）在某些时候执行的各种 GLUT 功能。如何围绕 GLUT 开发这种风格的游戏引擎，或者换一种方式来问，我怎样才能最成功地将 GLUT 与我的引擎隔离开来？是否可以让 GLUT 为外部程序生成这样一个交错的事件列表？例如，Haskell 如何处理这个问题？

【问题讨论】：

标签： events opengl scheme functional-programming

【解决方案1】：

您将很难实现功能性图形系统。即使是到 GLUT 的 Haskell 绑定也使用命令式编程，通过 IO monad。我听到的最接近您尝试做的事情是 Functional Reactive Programming，但这些库还没有准备好迎接黄金时段，而且严重缺乏真实世界的教程。

【讨论】：

【解决方案2】：

您可以查看FieldTrip 库，了解有关功能图形的一些想法。

【讨论】：

【解决方案3】：

对于像openGL这样的状态机来说，它有状态是非常重要的！

当副作用是将一组东西绘制到屏幕上时，我不明白如何进行无副作用的函数式编程。

【讨论】：

这里的问题不是太多的副作用，而是如何处理GLUT在需要完成时异步回调的事实，而不是建立函数依赖关系。我想知道是否有办法让它从某种外部 GLUT 的角度来看，但也许这不是一个非常明确的想法。
抱歉，除了用于 openGL 的字体插件之外，我还没有使用过 GLUT。我在想openGL pop/push 状态。真的帮不了你。
> 当副作用是将一组东西绘制到屏幕上时，我不明白如何进行无副作用的函数式编程。尽管最后的输出步骤绘制了东西（“打印”），但我们以纯函数方式使用数字进行编程。同样，功能图形的关键是提供一种具有丰富且有用的代数的数据类型，其中组合（编程模型）发生，具有精确且易于处理的语义并且没有副作用。然后就不用担心如何打印数字了。

【解决方案4】：

写下这个问题让我思考了一下，我开始怀疑答案是否在于利用协同程序。如果游戏是由 GLUT idle 和 display 调用触发的功能协同程序，这将很好地将游戏逻辑与 GLUT 的架构分开。例如，很可能是那一套！无法避免，但如果使用 GLUT 回调设置！只是为了修改被送入协同程序的流，这可能会创建一个非常好的边界。对此有什么想法吗？在了解更多信息之前，我必须获得更多关于协同程序的经验..

【讨论】：

从我对使用 call/cc 阅读协同程序实现的记忆中，我认为您仍然必须在协同程序库的深处使用set!。不过我不会让它打扰你。 :) 尽可能多地隐藏状态更改仍然可能会清理您的代码很多。
是的，我想我开始喜欢这个主意了。如果我不能摆脱 set!，那么下一个最好的办法是让它尽可能接近 GLUT，同时通过将我的代码表示为看似是惰性列表的单个函数的东西来疏远我的代码。 GLUT 部分就是一个惰性事件列表的生成器。无论如何都在努力.. :)