## FRP Morning 9/11/18

* TOC
{: toc }

### From Debugging Towards Live Tuing of Reactive Applications

I was sent this paper by Jonathan Edwards for feedback to the authors. It was recently accepted into LIVE. It was right up my alley. It's the notion of taking the DAG visualization of a FRP app, but making it editable at the visualization level, similar to a node-and-wire environment, such as Facebook Origami. It was a fun read, and I gave a few notes to the authors.

### Beautiful Conal Quotes

There are a few things Conal said that have really stuck with me, so I took the time to transcribe them and put them [here](/notes/conal-elliot). But I'll paste them below as well because they are just so wonderful:

> It’s important to me that you cannot look in a behavior and say like “when does it change (change in the sense of events)?” Because in order to answer that question One would need a more complex semantic model.  
> Now, many or most so-called FRP systems I see out there do have some notion of “when does something change.” And every one of those breaks the semantic model. 
>  
> It’s like you have arithmetic, right? So FRP is arithmetic for time-varying quantities of all sorts of types. By arithmetic, I mean some algebra, some set of operators that have nice laws, nice properties. And imagine if you thought of arithmetic as about compositional structure or about the express that you evaluated.   
>  
> If you added 3 and 4, can you tell tell the difference between that and what you get by adding 2 and 5? It’s very important to the laws of arithmetic that you cannot tell the difference. If you could tell the difference, then what you would have would not be a type of numbers with a nice set of operations. It would be something more like a type of trees or something like that. And there would be no interesting equational properties. And you’d have something very complicated. And you’d have to talk about your API instead of talking about... You wouldn’t be doing math, you’d be doing data structure manipulation. 
>   
> For instance every time you hear somebody talk about FRP in terms of graphs or propagation or something like that, they are missing the point entirely. Because they are taking about some sort of operational, mechanistic model, not about what it means.   
>  
> And what I see happen over and over is not only do people generate a complex model but they don’t know it’s complex because they haven’t looked at it precisely. And they thwart most attempts to do nontrivial optimization’s because they’ve exposed too much information. So I want to make it as abstract and useful as possible, so it’s simple for somebody to think about, and I can do radically different sorts of optimization experiments. 

Of course, this doesn't mean that a "debugging engine" can't break these abstractions to keep track of these things so as to aid you in understanding. The key is that the programmer cannot break this abstraction at the semantic level, so we can do creative optimizations, etc. In other words, I can write `3+4=2+5` and we can talk about each of those four numbers indepdenently. They don't immedialy collapse to `7=7` the instant I write them down.

I also love this beautiful quote about functions as boxes and values as flowing across arrows: 

> It's an inherently first-order visualization. In other words, the visualization itself makes a hard visually syntactic distinction between functions and values. What's great about functional programing is that functions are values... [with] visual arrows, with every composition, you get something more complex than what you had before. Complexity grows and grows and grows. Visual langauges are very sparse, rather than a dense notation. So pretty quickly you get swamped... You use up a lot of space not saying very much.

### Feyman Method to Solving FRP Notation

The method is:

1. Write down the problem.
2. Think very hard.
3. Write down the solution.

Here's what that looked like:

![image](https://user-images.githubusercontent.com/2288939/45373019-63f0ba80-b5bc-11e8-92c0-e7e894314bfc.png)

What I decided was (for now) to give up on wires and arrows to visualize flow and depedencies. Instead I want to be more creative about showing those things, such as spatial arrangement, labelling (including colors, words, and on-hover interactions), etc.

I then pseudo-coded a few classic GUI problems. (I may steal other problems from [7GUIS](https://eugenkiss.github.io/7guis/).)

What I discovered here is that the classic notation of FP isn't all that bad. (That's not quite true. For example, [Conal's original bouncing ball](https://futureofcoding.org/log#bouncing-ball-solved) is tough to read. More on this in the todos below...)

The problems are:

#### 1. Expression construction made "live" & "concrete"

You want to be able to construct these expressions in any order, such as:

A) Start with an widget, like a button, and then derive some state from it, and then plop it back in itself.

B) Start with a notion of some state (you haven't yet defined), and build up a widget from that state, which then can be defined in terms of the widget. 

Self-referencing makes this possible more difficult, but nothing a structure-y editor couldn't solve.

#### 2. See the dataflow behind behaviors & events

I dont see any reason why this shouldn't be possible as an "overlay" of some sort on top of the classic FP notation.

I can also imagine an on-hover interaction to functions that allow you to visualize how they transform their inputs into their output, such as [this one](https://futureofcoding.org/log#lets-visualize-all-the-fp-list-operators). 

It'd be neat to have an over-arching shape of an application so you can visually get a sense for how it fits together, but I don't know if anyone's done that yet. Node-and-wires don't tell you much: they tell you less than regular FP syntax, and often in more confusing ways.

#### What's the type of FRP Widgets?

I'm not clear on what the "type" of widgets should be -- that is, what they "return". 

Are they a "structure" of some sort that you can then get various event streams (such as click) "from"? 

Or should they simply return the (or a list of the) event stream(s) that they "contain"?

### Blur the line between front & backend

In the past I called this idea "higher level HTTP requests" or "HTTP = JQuery". Here are some thoughts I put on Twitter along these lines yesterday:

<div id="tttt_1038822763606302721" data-option="1"><strong><a href="https://threadreaderapp.com/thread/1038822763606302721.html">Thread by @stevekrouse: "been daydreaming about a web framework that blurs the lines betwn front & backend even more than @meteorjs. You (somehow) declare data r […]"</a></strong></div><script async src="https://threadreaderapp.com/embed/1038822763606302721.js" charset="utf-8"></script>

### Next steps 9/11/18

* pseudo-code more GUI problems, possibly from [7GUIS](https://eugenkiss.github.io/7guis/), building up to ToDoMVC
* think about what and where traditional FRP syntax is difficult (such as [Conal's original bouncing ball](https://futureofcoding.org/log#bouncing-ball-solved)), and also more modern syntaxes... re-check out PureScript in this vein

Author: Steve Krouse

notes/conal-elliot.md

@@ -10,8 +10,18 @@ title: Conal Elliot
 
 ## Haskellcast
 
-* Push pull FRP: modern reformulation in applicative etc. Algebra for time varying values. Analogy: you can't say "when a reactive behavior changes" (once you build up an event such as red until mouse click then blue) but many FRP systems do this. It's like making a distinction between 2+5 and 3+4. Turns math into a tree datat structure manipulation and you loose lots of the properties. 
-* FRP as a graph is too complex. Exposes too much info. Not abstract enough for optimization. 
+> It’s important to me that you cannot look in a behavior and say like “when does it change (change in the sense of events)?” Because in order to answer that question One would need a more complex semantic model.  
+> Now, many or most so-called FRP systems I see out there do have some notion of “when does something change.” And every one of those breaks the semantic model. 
+>  
+> It’s like you have arithmetic, right? So FRP is arithmetic for time-varying quantities of all sorts of types. By arithmetic, I mean some algebra, some set of operators that have nice laws, nice properties. And imagine if you thought of arithmetic as about compositional structure or about the express that you evaluated.   
+>  
+> If you added 3 and 4, can you tell tell the difference between that and what you get by adding 2 and 5? It’s very important to the laws of arithmetic that you cannot tell the difference. If you could tell the difference, then what you would have would not be a type of numbers with a nice set of operations. It would be something more like a type of trees or something like that. And there would be no interesting equational properties. And you’d have something very complicated. And you’d have to talk about your API instead of talking about... You wouldn’t be doing math, you’d be doing data structure manipulation. 
+>   
+> For instance every time you hear somebody talk about FRP in terms of graphs or propagation or something like that, they are missing the point entirely. Because they are taking about some sort of operational, mechanistic model, not about what it means.   
+>  
+> And what I see happen over and over is not only do people generate a complex model but they don’t know it’s complex because they haven’t looked at it precisely. And they thwart most attempts to do nontrivial optimization’s because they’ve exposed too much information. So I want to make it as abstract and useful as possible, so it’s simple for somebody to think about, and I can do radically different sorts of optimization experiments. 
+
+* Push pull FRP: modern reformulation in applicative etc.
 * Un-amb (used to pick between two algorithms that may work), Least upper bound, lattice, denotational semantics (Dana scott(deep)-chris strachy(simple, very useful) semantics)
   * Chris strachy wanted to translate from arbitrary programming language to lambda calculus to understand goto and loops with breaks (and he understood continuations). 
   * Denotational semantics: express lang as AST (recursive algebraic data type) and map to this language of functions. It's compositional: meaning of expression is meaning of sub expressions.