Initial send within a listen()

[dakom]

When creating some FRP which is a result of a listen(), that new FRP may want to immediately set initial values. However, send() is not immediately possible due to "You are not allowed to use send() inside a Sodium callback" - as well as the fact that the listener for that send won't be setup yet.

What is the recommended solution to send out initial values?

Assuming something like const mySend = () => myStream.send(val)

A cheap workaround is to use a setTimeout(mySend) or Promise.resolve().then(mySend) and delay the send(), but maybe there's a better way? (aside, seems to me the promise route is better but setTimeout is clearer to make the point... I put together a little fiddle to investigate that: https://jsfiddle.net/dakom/2bqLtetL/)

[the-real-blackh]

Hi David,

Delaying the operation till later is the recommended way. Consider doing that with all your 'listen' handlers. If you need it to be synced up with the FRP more closely, consider using 'switch'.

Steve

[dakom]

Seems like there's way more simply-describable use cases for Switch() than I originally realized (e.g. "initial setup", "unmerge", ...)

Just an idea - maybe you could put together a short list of some of those, and one of these days people can implement them in the examples? (I'm happy to take a stab at it with typescript, eventually)

[Ziriax]

IMHO when you immediately want to send back values in your listener, it is an indication your app is not doing FRP correctly.

In an ideal FRP world:

• at time T, one external event fires (e.g. a button is pressed).

• in Sodium, this event is send to a StreamSink. These stream-sinks are the input nodes of the FRP dataflow graph.

• from the point of view of the FRP dataflow graph, time T is frozen during the update. This means that although the real world clock advances while the FRP dataflow graph is updated, the logical FRP time does not. This also means that no other external event is allowed to fire at time T, since then we would have two external events at the same time T (e.g. the user pressed two buttons at exactly the same time). Note that other reactive systems might allow multiple external events at the same time, but Sodium doesn't. In Sodium, if you want multiple events at the same time (say a videogame where the X and A buttons are pressed at the same 'input device sampling time'), you just pass an array or the input-device-state as a single external event.

• the FRP system will update all dependent nodes in the FRP graph in a glitch-free way (~= breadth first traversal of the dataflow graph). E.g. when a node at FRP time T computes z=x+y, and x is dependent on the initiating external event, then the node cannot fire 'z changed' as soon as x changes, since y might also be dependent on the external event. Systems like Reactive Extensions (RxJS) don't do this, so when both x and y would change, 'z changed' will fire twice. This causes glitches (temporary inconsistent values), and a lot of potentional computational overhead (imagine the external event to be an animation timer that is connected to N nodes, each node having two inputs, the timer itself, and another similar node. Then the total number of updates in RxJS will be N*N/2, while in Sodium, it will be just N. However, each update in Sodium is more expensive, but since the complexity of Sodium is O(N) and not O(N*N) like RxJS, it will have much better performance for complicated FRP graphs with lots of inter-dependencies.

• listeners are notified when nodes produce an output. Ideally you only have listeners to the output nodes of the dataflow graph (unless for debugging). These listeners should update the user-interface, or control external motors, lights, or other actuators. But during this update, no other events that would active the FRP graph again are allowed the fire, because the FRP circuit is not yet updated. Note that a reactive system could make a difference between internal and external listeners, and only notify the external listeners after the whole graph is updated. But I don't think Sodium does this.

• so yes, if you really really must send a value to a StreamSink while listening, then delay this until after the FRP graph is updated (I think Sodium has a Transaction concept for that). But ideally, you never do this.

[dakom]

IMHO when you immediately want to send back values in your listener, it is an indication your app is not doing FRP correctly.

100%! See http://sodium.nz/t/understanding-listen/171 While I still struggle with it a bit, I totally agree that treating listeners as the end point is crucial and not doing so is almost always a red flag, at least it seems that way to me so far

Thanks for a great breakdown @Ziriax, it's very helpful to see these concepts elucidated in various ways.

The reason I'm not particularly worried about the delayed-send issue in this particular use case, which I forgot to mention, is that it happens to be for code that is setting up some tests/mocks and won't actually run in the production build

Out of curiousity - in the typescript implementation, is there a way of doing this inherently with defer() or something? setTimeout (or now promise) is an idiomatic way of asynchronous js code but I'm curious if there's something more native to sodium itself.

[Ziriax]

Please note that my breakdown is my own mental model, it might not be correct for Sodium!

I don't use the Typescript version, but at first sight it is missing a public static Transaction.post method that might be used for delaying an action.

I'm not sure why this code wasn't added, but looking at the Java version, it seems easy to cook your own version:

public static void post(final Runnable action) {
	    Transaction.run(new Handler<Transaction>() {
            public void run(Transaction trans) {
                // -1 will mean it runs before anything split/deferred, and will run
                // outside a transaction context.
                trans.post_(-1, new Handler<Transaction>() {
                    public void run(Transaction trans) {
                        action.run();
                    }
                });
            }
	    });
	}

Since the Typescript Transaction class does have run and post(childIx: number, action: () => void): void methods, the Java code above would be easy to transfer.

Otherwise I would use setImmediate or ASAP in Typescript, see the NPM registry

[dakom]

at first sight it is missing a public static Transaction.post method that might be used for delaying an action.

Interesting! @the-real-blackh - what are your thoughts on adding Transaction.post() ? Can you elaborate a bit more on the use case for it? (no rush, just curious)

Otherwise I would use setImmediate or ASAP in Typescript, see the NPM registry

I looked more into how the js event loop works. Seems like setting it as a microtask via Promise.resolve().then() is good since all the listeners will have been setup in the current stack execution before the microtasks are run. Explained in more detail @ https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

[jam40jeff]

I agree with others that the Send() here sounds like something that could be replaced with more "proper" FRP.

However, I have recently come across a case where I did in fact need to Listen(), then Send(), and I did so with Transaction.Post, which will schedule the Send to happen in a new Transaction on the same thread as soon as the current Transaction completes.

[Ziriax]

So then Transaction.post should be added to the Typescript version I guess?

[jam40jeff]

I would think it should be. In addition to being a part of the C# and F# implementations, it is part of the Java implementation, which I believe counts as having Stephen's blessing.

It allows us to do recursive FRP logic that would otherwise be impossible (or at least involve nondeterministic Sends within a Task/Promise).

[the-real-blackh]

Transaction.post() exists, but I think I neglected to export it. I'm happy to change this and make it public.

[dakom]

fyi I'm almost done moving the typescript dev environment from webpack to fusebox and the experience will be way better, but there's some bugs in fusebox itself that are holding it back... for a simple change like this I don't think it matters, just fyi

[jam40jeff]

A couple other points I meant to make:

(1) My use case for Listen, followed by a Send in a Transaction.Post was because of "recursive" logic (changes to a property of an item switched on within a collection needed to be able to conditionally modify the contents of that collection). You must be very careful with recursive logic, as it can be easy to create forever loops (which would quickly cause a stack overflow). Sodium cannot do the topological sort when there is a dependency loop (and I actually put code in Sodium C# 2.1 to detect these loop and throw an exception), so I think this makes the most sense as far as how to handle "stepping" recursive logic (a new Transaction for each step).

(2) Per Ziriax's comment:

In Sodium, if you want multiple events at the same time (say a videogame where the X and A buttons are pressed at the same 'input device sampling time'), you just pass an array or the input-device-state as a single external event.

I just wanted to point out that this can also be done by explicitly calling Send on two different sinks within a Transaction.Run call.

[Ziriax]

I just wanted to point out that this can also be done by explicitly calling Send on two different sinks within a Transaction.Run call.

Yes, but these two sends will be regarded as two events at different times no?

[the-real-blackh]

Transaction.post() guarantees to run the action will run immediately after the current transaction and before any new transaction (e.g. on another thread).

[jam40jeff]

Yes, but these two sends will be regarded as two events at different times no?

No, all Send calls within a Transaction will behave as if they happened simultaneously. You can easily test this by listening to a Lift call on two CellSinks. Then Send a value to both CellSinks outside of a Transaction and then within a Transaction. You will see a value on each Send call outside of the Transaction, but only one for the entire Transaction despite the two Send calls.

Keep in mind that Send can only be called once on a given sink unless you provide a coalesce function when constructing the sink. (The default coalesce function for a sink is to simply throw an exception if more than one value is seen within a Transaction.)

[Ziriax]

Oh that is very cool! So Sodium does support simultaneous input events, as long as these come from different sources. Nice