rspl

A powerful stream processor language with roots in functional programming (see Generalising Monads to Arrows) embedded in Rust and supplemented with adaptations of popular design patterns.

• power:
  • syntactically explicit process control
  • arbitrary mixing of reactive (event-driven) and generative (demand-driven) processing
  • high-level stream processor combinators (combinator-driven)
  • agnostic regarding input-stream implementation
• design patterns (also see Released API docs):
  • type-state pattern for event-driven programming
  • state-passing pattern for demand-driven programming
• Rust:
  • safety:
    • no dependencies (apart from crossbeam-option)
    • thoroughly tested
    • memory-safety: no unsafe code
  • no_std option
  • high-level library for low-level purposes

For documentation, see Released API docs. In particular, you can find a design and usage description there.

Related Work

One of rspl's earliest ancestors seems to be FUDGETS: a graphical user-interface in a lazy functional language and the corresponding implementation. Fudgets can be thought of as stream processors that process streams both at a high and low level, where the high-level processing is responsible for coordination with the environment and the low-level for the actual task. The use of fudgets is also briefly discussed in Generalising Monads to Arrows.
As the origins of rspl date back quite some time, it is not surprising that there is significant theoretical work on the subject. For example, Representations of Stream Processors Using Nested Fixed Points is a paper on the semantics of rspl-like stream processors, while in Termination Checking Nested Inductive and Coinductive Types, they serve as an example for understanding the termination checking of modern proof assistants.
There is also more recent practical work worth mentioning. Quiver is a Haskell library that is very similar to rspl (and claims to generalize the more famous but harder-to-understand pipes). The main difference is that Quiver's language constructs for input and output are totally symmetric, whereas rspl reflects the intuitive asymmetry of stream processing regarding input and output.
Last but not least, let us mention strymonas. Although its take on stream processing differs from rspl, it is still interesting due to its property of stream fusion. It would be nice to have an efficient composition combinator in rspl with the same property; however, rspl's composition combinator does not currently achieve this.

Future Work

rspl is not quite finished yet. Several important tasks remain:

• Little effort has been put into improving efficiency so far. The first step in that regard is benchmarking to see how rspl performs. Interesting competitors here are Quiver and strymonas - the former due to its similarity to rspl and the latter due to its performance claims. The results will guide the next steps. However, we intend to check whether rspl can exploit parallelism regardless of those results.
• rspl aims to support use in embedded Rust. As of yet, while the standard library is not strictly needed, an allocator is. We have two approaches in mind to remove the necessity of a heap:
  • We could try to reimplement rspl following the low-level approach discussed here (as .md file) and here (as .rs file).
  • rspl uses the allocator only for some Boxes, and it is conceivable to store those on "mini-heaps" residing in stack frames (compare smallbox). However, this approach requires further feasibility analysis first.
• You can never have enough combinators. Expect more to come - specifically, fudgets are currently lacking. Moreover, asynchronous versions of existing combinators (like map) will be considered.

Contributing

If you want to contribute: CONTRIBUTING.

Security

For security-related issues, see: SECURITY.