Regarding Functional Reactive Programming

[cubuspl42]

Hello,

thank you for creating this library! It looks very interesting and promising.

I've noticed you used the term "FRP" in the description, and obviously the library seems to be an FRP implementation (or at very least, strongly inspired by FRP).

What's your FRP background? What are your opinions on FRP? Are you basing your work on Conal Elliot's FRP semantics? What other FRP solutions is Airstream inspired by?

I'm asking out of interest; I'm very interested in practical FRP implementations, especially all efforts that incorporate mixing reactive operations with I/O.

[raquo]

Hi, I don't really have much of an FRP background. Airstream is mostly a result of practical pain from trying other solutions.

Originally I got into all this after trying Cycle.js and thus Andre Staltz's work. In fact, the first version of Laminar used his xstream.js, before I made Airstream. And Airstream's internals take some inspirations from Xstream, including shared execution and just the basic model of observables and listeners, as I've read the xstream.js source code to understand how such libraries are implemented.

The way Laminar binds FRP to the DOM was originally inspired by Outwatch, but then I moved away from virtual dom because it doesn't interact very well with virtual DOM (more on this here). I knew it was possible because I've used knockout.js before which has somewhat similar ideas, but also because of all my Laminar work to date I already knew what needs to happen under the hood.

Scala.rx was another inspiration especially for signal semantics and error handling.

I didn't just borrow the good ideas from all these libraries but also did things differently than those libraries because they didn't work for me. For example, dealing with MemoryStream in xstream.js and seeing the filter caveat in Scala.rx made me separate the concepts of signals and streams.

I don't quite remember what exactly inspired the ownership feature. The need for it was obvious as I hated to do manual cleanups of subscriptions, but I don't remember how I came to it. Certainly didn't copy it from any other streaming / frp library, I'm not aware of any that have a similar mechanic. Although Scala.rx has something like that, even if it's hidden from view by macros and stuff. So maybe that.

Same for using topological rank to prevent (or, well, localize, if we're being completely honest) FRP glitches – don't quite remember how I arrived at this solution. I've done some research, skimmed some papers and stackoverflows. Looked at a few streaming libraries. Pretty sure Conal's work occasionally came up in those searches, but I don't remember what, if anything, I got directly out of it.

The split operator I came up with after trying to find a more ergonomic solution for rendering lists of children in Laminar. Essentially, I tried to apply the concept of keys from React.js to a library without virtual DOM.

Airstream also originally had a State type, a strict alternative to Signal, which was inspired by Scala.rx I guess, but that didn't work out due to memory management footguns, and was dropped.

[cubuspl42]

Thank you very much for your answer.

made me separate the concepts of signals and streams.

In FRP they have always been separated, since 1997 ;) Surprisingly, till this day people feel the need to merge them, which I absolutely don't understand.

I don't quite remember what exactly inspired the ownership feature.

Ownership is a very interesting problem in FRP implementations (or even semantics!), I totally agree. To be honest, I haven't yet found time to fully analyze your solution, but I surely will. I personally have attempted to make progress in this field, but the best solutions are difficult to implement in most languages, sadly.

Same for using topological rank to prevent (or, well, localize, if we're being completely honest) FRP glitches

What do you mean by "localize"?

Yes, there are a few ways to eliminate glitches. I assume you use the priority queue based approach, like in Deprecating the Observer Pattern? I personally had really bad experience with the Sodium JavaScript implementation of that algorithm, I had (by orders of magnitude) better performance results using nearly brute-force push-pull approach, which I found intriguing. It's possible that there was something very inefficient with Sodium implementation, but I don't know what. I tried to replace the priority queue with other implementations and it didn't really help.

[raquo]

What do you mean by "localize"?

Docs explain that in more detail, but: Airstream has no FRP glitches within a Transaction. However, when you make EventBus emit an event, that always happens in a new transaction. Same for Var, same for the flatten / flatMap operators. The reason is the same – this functionality allows you to create loops of observables, and so my topological rank implementation doesn't work anymore as it assumes that observables form an acyclic directed graph (they do, but only within a transaction. With event bus or other methods you can make an observable depend on itself).

And so, what I mean by "localize" is that Airstream can have FRP glitches, but only transaction boundaries can cause them. Well, perhaps "localize" is not the best word for that. Just wanted to point out that glitches are not completely eliminated in Airstream.

In practice though this approach has completely resolved the issue of glitches for me, but that's because I don't use EventBus-es and such without a good reason. And those good reasons tend to preclude the possibility of glitches even despite the lack of built-in protection, e.g. using an EventBus to collect user events from independent children components means that those events are independent from each other, and so will not happen in the same transaction, and so EventBus will not screw up the timing or cause additional glitches by creating a new transaction for each of those events.

I assume you use the priority queue based approach, like in Deprecating the Observer Pattern?

Yes, I do use a priority queue based on topological rank, and I did read that paper early on (must have found a reference to it in Scala.rx docs), so that must be where I picked it up! I don't remember what exactly the paper says now though.

Re: performance, I don't think there are enough events flying around in the browser environment to cause a significant slowdown from the priority queue. In Airstream topo rank of an observable is static. The priority queue only lasts for the duration and scope of the Transaction. How many observables do you need to combineWith, all of them emitting an event in the same transaction, for ranking them by a static integer on such an event to become a performance problem? I haven't run the numbers, but I don't expect it to be a significant problem for typical Airstream use cases.

PS moving this to discussions, just like the others. Let's continue there.

[raquo]

The algorithm from Deprecating the Observer Pattern should be able to handle higher order constructions, in FRP sometimes called "dynamic switching", which flatten and flatMap are examples of.

Forgive me for being too lazy to read the paper again right now, but is this possible because they're calculating topological rank dynamically as opposed to statically like I do? In my case, each observable instance has a field topoRank which is calculated when the observable initializes, and it never changes.

So if I have stream2 = stream1.flatten, I can't know the "real" topoRank of stream2 statically, because it depends on which streams stream1 emits: the topoRank of stream2 would be different after each time that stream1 emits. But I only have static topo ranks, so I have to make stream2.topoRank = 1 and make stream2 emit events in a new transaction (topoRank only matters within a transaction, so since stream2 does not depend on any observables that emit in this new transaction, it can have a topoRank of 1).

This means I don't need to compute topoRank-s when emitting events. I wonder if the need to do that is the reason for performance issues you mentioned. I imagine it could get quite costly to traverse the observable graph on every event to determine the topo rank.

[cubuspl42]

but is this possible because they're calculating topological rank dynamically as opposed to statically like I do?

More or less so, if I recall correctly. Not for the whole graph, but for a subgraph affected by the specific switch that occurred. And it also required resorting the queue, if I'm not wrong. The author suggested that, in practice, the graph often "gets used to" specific switching patterns and the ranks are already OK after the switch, so the re-ranking doesn't happen after that often. Please note that I'm also not 100% confident, I know the algorithm (and it's possibilities) more or less, but to be totally sure you'd have to refer to the paper itself.

By the way, to be honest I'm not sure if I correctly understand the concept of switching the event stream. Note that in Sodium, you can only switch cell of streams (Airstream nomenclature: signal of event streams) and cell of cells (signal of signals). It has very specific semantics and for me it's intuitive. I'm not really sure what switching the stream (of streams or cells/signals) means.

[raquo]

Flattening an observable in Airstream can be achieved in several different ways, and requires an implicit instance of FlattenStrategy. The concept of "switching" is the default for all supported types. Here's an explanation from ReactiveX: http://reactivex.io/documentation/operators/switch.html

Switch subscribes to an Observable that emits Observables. Each time it observes one of these emitted Observables, the Observable returned by Switch unsubscribes from the previously-emitted Observable begins emitting items from the latest Observable.

To adapt for streams in Airstream, replace "Observable" with "stream", and "switch" with "flatten" (using the default FlattenStrategy) in that explanation.

[raquo]

The marble diagram on that page should explain better than words.

[cubuspl42]

Mhm, I get it. It's equivalent to switchS on a Cell that's initialized with empty stream, aka never. Personally, I have a mindset that switching is meaningful only on cells/signals, but it's surely biased.