Clojurians Log v2

> signals themselves are not references They're not equivalent, but they have a common property - being a stable identity observable as a succession of states. The difference is, while a reference can be mutated arbitrarily after construction, a signal's state is backed by an effect that is fully defined at construction and its interface is read-only. The effect can be anything - a pure computation from other signals' states, a state machine derived from an event stream, the successive states of a reference, etc.

I'm not an expert on Conal's work but I do think his signals are conceptually equivalent to continuous flows in missionary, and therefore also equivalent to electric expressions.

Thanks @leonoel 🙏🏼 That's exactly the nudge I needed, missionary's flows and concepts were on my reading list for a long time, it's time to dig in 😁

http://conal.net/papers/genuinely-functional-guis.pdf (Courtney, Elliot 2001)

• electric functions (e/fn) are essentially signal transformers • in missionary, clojure functions of Flow -> Flow are flow transformers

Thanks @dustingetz 🙏 To my understanding signal transformers are just lifted functions, right? They were simpler for me to understand, what I wonder more about are the signals themselves and especially "source" signals (i.e not derived, if that terminology makes sense). I listened to some of Conal's talks recently and he stressed continuous time and denotational semantics for signals and I'm trying to understand what that looks like. The only things I'm familiar with are getters/setters (like reactive atoms, or solid signals or w/e state library...) and the set function feels quite imperative to me. And reactive streams (like cyclejs or rxjs). I think cyclejs where you'd query for an input or a button and create a stream out of it is the closest to what Conal was demonstrating in this paper, but I'm not sure. I remembered that you explained signals and streams to me and wondered if you based some of your work directly on his papers and I could just see what he meant in your work. So I suppose my question boils down to: do you know what a signal (as meant by Conal) looks like? I think that it's not a getter/setter (atom) Do missionary / electric implements that? P.S @dustingetz I find myself referring to your article about streams vs. signals quite a lot, it's great 👏 , thanks again 🙏

when courtney says > A signal is a function from time to a value: > Signal α = Time → α i think this is rather misleading, I think time is not an explicit parameter, they are trying to invoke the intuition that a signal can be plotted like in math and therefore has a time axis, but in actual software implementations of signals, time always means "latest, right now". If it didn't mean that, then it would require infinite memory to be able to rewind the state to any past time.

Yeah that sounds like a required "optimization". I still wonder how you change a signal without setting it imperatively. In electric, if I recall correctly you can create a signal out of an atom and then you just set the atom and the signal changes, the same for the db and input (I think). I think that in the paper they don't have setters, all the signals change from "outside" (i.e some external event like click or typing). Maybe the point is that the atom and db and what have you, live "outside" of the signals system and everything inside is "pure"? 🤔 Then it's basically the same, and a signal (created from an atom) that changes by an input's onChange and the signal in paper are the same thing?

the paper is focusing on the pure bits by hiding the imperative IO in a function runGUI , this is the sentence where they hand wave away this entire problem > The implementation of runGUI handles all low-level (imperative) communication with the graphics library to read primitive window events and draw > pictures on the screen.

In short, I think your understanding is correct

Leo calls input/output references "ports" - https://gist.github.com/dustingetz/08c87050df3a26874d41886777422e8e

in missionary, signals themselves are not references, they are derived state which is downstream from the process inputs. The input ports are references. So imagine a reactive DAG – the DAG nodes might be pure functions, it is the inputs to the DAG that are references. The reactive computation is default parked, until an input port changes, at which point the DAG will reflow until it reaches the next fixed point and parks until the next input port changes

IIUC, Leo may correct some details

Thanks @dustingetz 🙏 As usual, talking with you shed light 😁