#functional reactive programming

I was mildly surprised to learn that the Promise class has been built-in to JavaScript. I was trying to fully grok the functional library Bacon when I ran into the JavaScript documentation for Promise. A Promise looks like this :

var p = new Promise( /* executor */ function(resolve, reject) { ... } );

A Promise can be in one of three states at all times : Pending, Fulfilled, or Rejected. This is…

I wrote a little demo in order to learn how to actually wire things together and execute Tasks, as well as how I might create a Service that could be used through out an app. I learned a few things during this process.

Although Native implementations are attractive from a re-use stand point, they're really fragile since they depend on compiler details.

It would be better to simply have a JS portion of the app that subscribes to a port and reacts to it.

A second exploration, forthcoming, will delve into how to use this, how it differs from a more Task oriented set up, and integration thereinto.

Thereinto is an officially listed word, albeit archaic.

How to actually wire user events through Tasks, into the evaluation pipeline, and finally take the results back into updates to the model.

The first item isn't really all that important, more just something to consider when creating services your own app will make use of. Elm-http makes use of a Native module to take care of actually performing the side-effect of trying to make an HTTP connection.

The second wasn't originally in this, just something which surprised me.

The third, however, will take up the bulk of this.

Digging into actual examples

Since I'd wanted to have some sort of Service which reacts to User Input and couldn't make heads nor tails of how to connect a signal of user Actions to services and back into updates, I decided to really dig into the examples of such interaction that were provided and rewrite them until I could understand them.

One of the examples provided is a simple ZIP code searcher which takes a valid ZIP code the user enters and sends a search request to api.zippopotam.us. Looking just at the imports didn't show anything particularly interesting, not that I'd expected anything there, but this was a close-grain search so I had to check anyway. The rest of the app was split into View and Wiring.

The view itself didn't show much aside from using the more generic on rather than on{Event} thing, perhaps due to listening for input DOM events. Upon the event firing, a message would be sent to query.address, so looking at query (which presumably is a mailbox) would be a natural place to start in the following section, the Wiring.

The first part of Wiring is simply the main function, which of course has the usual type of Signal Html and although the use of Signal.map2 is odd, it's not too far out. The view, it should be noted, takes as arguments a String named value and a Result String (List String) named result, rather than the address and model seen in fuller App examples.

The second part is where we will start in, since that's actually the thing we were looking for: the query mailbox. We can see it's a mailbox of strings, which makes sense if it's receiving the values of the text input. We also see just below it the results mailbox, but we'll mostly ignore at the moment, merely noting it's there. The thing after that is the interesting part, since it's a port.

The port here is annotated port requests : Signal (Task x ()) and given the definition of port requests = Signal.map lookupZipCode query.signal |> Signal.map (\task -> Task.toResult task `andThen` Signal.send results.address)... Oy vey. Even rewriting the |> out of there doesn't clear anything up. What the hell are any of the types?

One thing that will save you some confusion is to note that Task.toResult has the type Task error value-> Task x (Result error value) and it's not some magical Task to Result converter, just a re-wrapper, thus allowing the use of andThen as-is rather than with any additional functions around its use.

At any rate, I'd tried dissecting that port line for awhile and couldn't make any headway, so decided to just start rewriting parts to make it clearer using what I knew to transform its current form into something more verbose, but more understandable, mostly by breaking the parts out into temporary values in a let in statement, resulting in this fatter port definition. This has the same end result, all of the same processing, but lacks the confusing all-in-one-ness of the original.

Now it's easier, not necessarily obvious but still easier, to see that we're starting out with the query.signal from earlier and mapping a function lookupZipCode across it, which thus becoming a Signal of Task String (List String) (or whatever lookupZipCode returns, it doesn't really matter to us here.) Then, the lookup zip code Tasks are turned into Results and sent off the results mailbox. While this is eventually apparent when looking back at the original, it's not initially clear to a newbie how it works, leading to this sort of rewriting becoming necessary.

And while we're on the topic of rewriting, let's rewrite the above description to be more "functional" in nature, because functional programming deals with "things" not "commands", or "nouns" and not "verbs".

We start with query.signal, a Signal of query Strings, then get a Signal of Tasks by getting a Task representing the zip-code lookup request for each query String, from there get a Result of that lookup Task, and finally get a Task representing the process of sending that result to the results mailbox.

Reading a bit more deeply through Dreamwriter, only its UI is written in Elm while the rest (App Logic) is written in CoffeeScript. it has numerous ports, one for each possible thing that may have to be performed by the App Logic. Thus only the App Logic itself actually does any interactions with the outside world while the UI merely manages the sundry inputs to draw the UI. This doesn't answer everything, but I do think it will at least prove useful in the background melange.

I decided to finally look at the mailing list because presumably I'm not the only person having trouble with this. Someone named Sridhar wrote up a long and winding (in a helpful way) post which itself iterates upon the very important concept of modeling things as data flow, not as commands, and on the fact that because of Elm's Pure, Mostly nature, it does not actually do anything that is sent to a mailbox.

Anything which affects, triggers effects in, or handles effects of the outside world most eventually flow through a port. That annoying thing which I didn't understand until now. I probably still don't understand it, yet, but I'm in a better place thanks to Sridhar.

A port which is a Signal of Tasks will actually have those tasks executed by the Elm run time. Even the Http library works this way.

Although I didn't notice this at first, looking in the module Native.Http, I see now that the send function doesn't actually do anything immediately, rather it returns a Task.asyncFunction, which itself actually executes the HTTP Request when it flows into a port.

Thus, even using the established libraries, and even those with Native parts, Tasks are only ever actually executed when they flow through a port.

As stated in Sridhar's post (and numerous times on the mailing list by various people trying to help nubs like me) a Task, as defined in Elmland, is not an actual execution unit that is happening, but rather the it is the description of an action that will happen at some point. Even the native JS side of a Task is a mere statement of what will happen, not what happens immediately. This was actually stated in the Reactivity tutorial, too, but I think that the tutorial is written from the standpoint of someone who's been in Functional land for a long time. Sridhar's post went a very long way to helping me begin reorienting my brain by providing a lot of useful background information and a bit more repetition of basic facts.

Edit: Thinking about it, there's one case in Elm where you don't use ports: Reaction to DOM Events. These seem to magically occur, but then they already have premade signals so I suppose that's fine. Or perhaps it should be stated that as Elm's primary purpose is to be a UI language, not a general purpose language, the implicit creation of Signals of various UI properties is something we can live with. Or are just assumed to be a given of the language environment. Something like that.

I don't even know where to start on the connection of actions or whatever to ports, so I'm going to start with just those facts I do know:

The output port must be a signal of some kind. Probably API Requests or whatever I define it as. It doesn't matter what it is, just that it's a signal of it. The type can be defined elsewhere.

Signals can't be created from nothing, and must always have a source, whether it's user input, a ticker, or whatever. Something environmental can be made into a signal, but it has to be something and not nothing.

Signals can be manipulated with various functions such as merge to combine multiple signals into one which has all their events, map to transform values from one signal into values in a new signal, filter to selectively accept or reject certain values from a signal for inclusion in a new signal, and so on.

I need to trigger API requests in reaction to various things:

The Console Log needs to refresh periodically, but not too often. The point being it needs to do this without user interaction. (The exact timing may be set up in JS at first until I have a better grasp of signal manipulation.)

Later on, Console commands need to be sent when the user hits enter on the command line, triggers a macro, or some other thing which trigger console commands.

It sounds like ultimately, my signal source is going to be a signal merged from a couple places:

Certain user actions (Console commands, server restart, etc.)

A Timer for various automatic periodic things. (Console log, server stats...)

As far as how to event start researching this, User Actions seems to be a pretty good place. I use StartApp because it simplifies starting the app, but I currently have no idea what goes on under the hood. I know that user actions are sent to addresses, but I'm not sure how that becomes a signal of actions.

Addresses, it turns out, are usually part of another structure called a Mailbox, which as it happens is a record with two parts: An address and a signal. Ah ha.

Another thing that helped was peering through the code of Evan's Elm implementation of TodoMVC, as he did not use StartApp here. Down at the bottom of Todo.elm, we see this: actions : Signal.Mailbox Action followed by a definition actions = Signal.mailbox NoOp and lo, a Mailbox is created. (As mentioned in the Docs, this also creates a Signal, which is itself impure, thus bolstering my statement of "pure, mostly". This also shows one of my 'facts' was incorrect, and that signals can be created willy nilly.) We also see the definition of main with type Signal Html, and model with type Signal Model. What's in these?

With main, we have main = Signal.map (view actions.address) model. Signal.map has the type Signal.map : (a -> result) -> Signal a -> Signal result, so we know that (view actions.address) is a function that takes a single Model value and returns a single Html value. view is of course Address Action -> Model -> Html but Address Action is already supplied with actions.address, so we're left with just Model -> Html, which looks correct. That leaves model on the end, there, which has the type Signal Model.

I see here that model has the definition model = Signal.foldp update initialModel actions.signal, and finally I see how actions ultimately result in new models. New messages are sent to actions.address, which thus result in those new actions appearing in actions.signal, which itself can be manipulated with the various Signal functions of map, foldp, filter, or whatever.

But wait, how do I use this knowledge with StartApp? StartApp doesn't appear to expose anything to do with a signal of actions. Indeed, it doesn't, as checking StartApp's source code it's plainly seen that actions : Signal.Mailbox Action only shows up in the let part of a let in block. That's no good. So there must be another way to do this without interacting with the Mailbox Action thing. I'll need to look around for an app that does pull information from a server on some user action and see what they do, presuming of course they're doing it correctly, whatever correctly is.

Just as an aside, while I don't know if it will actually make a difference here, Server APIs such as CreeperHost's are usually exposed as Services in JS frameworks, which live outside of the MVC portion.

There’s no intrinsic idea of state from this perspective. There’s just a change in an input resulting in a new output. State might be an implementation detail with how the app handles its inputs, but it’s not necessary. It’s not intrinsic to the idea.

Most problems worth solving have some intrinsic state. State can be essential. But that’s not how we treat it. We solve everything with state. Because we treat all the inputs to our app as different things—a touch event here, a web response there—we can’t combine them in any meaningful way. We can’t transform them uniformly. And so our only tool for dealing with all these different things is state. When our only tool is state, every problem looks like a stateful nail.

State is bad. State introduces complexity. And worse, it introduces complexity that grows more than linearly with the size of our app. We’re in the habit of constantly introducing more state into our app. New feature? New state. New complexity. New bugs.

But happily this perspective of our app’s output as a function of its inputs over time gives us a new tool: functional reactive programming. Functional reactive programming (FRP) is a paradigm built around the idea of time-varying values produced by time-varying functions.

an i/o library -- maybe it is language core, maybe not -- where the "read a file" function has a type like

readFile :: FilePath -> Observable String

observables are in the functional-reactive-programming sense: whenever an observable changes, all its dependents are automatically recalculated

so whenever the file's contents change, anything based on it will be recomputed!

i think this might work really well for the kinds of things grunt and gulp do? css minification, browserify or requirejs bundling, etc., and it should be a lot more performant than the current way of watching the source files for changes, since even if (say) a js bundle depends on a zillion files it won't need to recalculate the parts that didn't change