Journal entry for January 22, 2024

Today I worked on translating my Threepenny-GUI TodoMVC to my FRP library. Reflex-DOM seems to do GUI by using the PerformEvent transformer which I think is an EventWriter for IO actions, but looking at Threepenny-GUI it seems they just fire off actions whenever? I’m not entirely clear on the details of how to best implement this or what the reasons are for doing it a certain way.

Switching perspectives in an FRP app (functional/imperative? visible/hidden state?)

I’ve also had many thoughts or rather vague vibes come to me about how you should be able to switch the view around for an app like TodoMVC (or any interactive app I guess?) from “functional-functional” to “functional-imperative”. I’m not even sure what that means, now that the vibes have fleeted :')

Maybe: You can write FRP in a much more imperative way than usual by creating events out of nothing and add occurrences to them with a trigger or tellEvent. This is just as “purely functional” as using a state transformer for example. On the other hand you can always write the same thing while manually bubbling up the events.

I’m just remembering another aspect of this: suppose you want to know/keep some state like “the current number of to-do items”. You can do this explicitly incrementally with Reflex’ Incremental + PatchMap for example. But, you could also manually write out the way the counter changes with a more imperative feel, i.e. “when a new task is added, increase the counter”.

Another thing is that you can write a to-do app with an explicit list of tasks in a behavior, and manually add identity to each task with an integer etc. Or you can hide the state and only expose how the things you see on screen are changed by plumbing events.

It’s all very vague and I’d have to work out some examples to get a grasp on it.

Example

Consider the entry field for the todo list. When you press enter you want to clear it, so in a graphical environment you could select “on enter key” and then “do action”, click on the field, and select “set contents”, setting that to the empty string. This is obviously a very imperative way. But when you examine the field you should also be able to see the “functional perspective”: what influences the state of the field?

Similarly, the list of tasks can be seen the collection of “all initial tasks entered from the entry field + any modifications after the fact”, or the entry field could say “insert a task in the task list”.

FRP Smalltalk/tangible functional programming

I’ve also been thinking about the FRP-based Smalltalk/IDE. Would it be a natural solution to composable, incremental program definitions? Like where you’d write a let-binding it would actually be a behavior for each part. A behavior with identity. A denotative notion of identity is very important to make progress I think.

Then I’m not exactly sure what it means to “run” the programs. Like I’ve written about before, you want to be able to look at and explore the state of a program.

One interesting thing is that the state is fully determined by input + time.