rspl

一个具有函数式编程（见泛化 Monads 到 Arrows）根源，内置于 Rust 并辅以受欢迎的 设计模式 的强大流处理语言。

• 强大
  • 语法明确的进程控制
  • 任意混合反应式（事件驱动）和生成式（需求驱动）处理
  • 高级流处理组合子（组合子驱动）
  • 与输入流实现无关
• 设计模式（也见 发布的API文档）
  • 事件驱动编程的类型状态模式
  • 需求驱动编程的状态传递模式
• Rust
  • 安全性
    • 无依赖（除了 crossbeam-option）
    • 彻底测试
    • 内存安全性：无 unsafe 代码
  • no_std 选项
  • 用于低级目的的高级库

有关文档，请参阅 发布的API文档。特别是，您可以在那里找到设计和使用说明。

相关工作

rspl 的早期祖先之一似乎是 FUDGETS：在惰性函数式语言中的图形用户界面 及其相应的 实现。Fudgets 可以被认为是流处理器，它同时以高、低级别处理流，其中高级处理负责与环境协调，而低级处理负责实际任务。fudgets 的使用也在 泛化 Monads 到 Arrows 中简要讨论。
因此，由于rspl的起源可以追溯到很久以前，关于它的理论研究并不令人惊讶。例如，使用嵌套不动点的流处理器的表示是一篇关于类似于rspl的流处理器语义的论文，而在嵌套归纳和反归纳类型的终止性检查中，它们被用作理解现代证明辅助工具的终止性检查的示例。
但是，也有一些更近期的实际工作值得提及。Quiver是一个Haskell库，看起来与rspl非常相似（并声称可以推广更著名但更难理解的pipes）。主要区别在于，Quiver的输入和输出语言结构是完全对称的，而rspl则更反映了流处理在输入和输出方面的直观不对称性。
最后但同样重要的是，让我们提及strymonas。尽管其对流处理的理解与rspl不同，但由于其流融合的特性，它仍然对rspl很有趣。在rspl中有一个高效的组合算子将会有所帮助。然而，rspl的组合算子目前还没有达到这一点。

未来工作

rspl还没有完全完成。还有一些重要的事情要做

• 到目前为止，在提高效率方面几乎没有努力。在这方面要做的第一件事是进行一些基准测试，看看rspl真的有多糟糕。这里，有趣的竞争对手是Quiver和strymonas。前者由于其与rspl的相似性，后者则因其声称的性能。结果将指导进一步的过程。然而，无论结果如何，我们承诺要检查的是rspl能否以某种方式利用并行性。
• rspl旨在支持其在嵌入式Rust中的应用。到目前为止，虽然标准库不是严格必要的，但分配器是必要的。但我们有两个想法来消除对堆的必要性
  • 我们可以尝试按照这里（作为.md文件）和这里（作为.rs文件）中讨论的低级方法重新实现rspl。
  • rspl仅使用分配器来处理一些Box，可以想象将这些盒子存储在栈帧中的“迷你堆”上（比较smallbox）。然而，这种方法需要进一步的可行性分析。
• 组合子永远都不嫌多。所以你可以期待更多。特别是，fudgets还缺乏。此外，还会考虑现有组合子的异步版本（如map）。

贡献

如果你想贡献：请参阅CONTRIBUTING。

安全

有关安全相关问题，请参阅：SECURITY。