## Incorporated Jonathan Edwards feedback on frp draft 2

* TOC
{: toc }

As usual I received some prompt and insightful feedback from Jonathan Edwards yesterday:

> Abstract   
> scalable->modular, larger->entire   
> “this paper shows how higher-order and cyclic streams can improve comprehensibility.”

✔ 

> Introduction  
> they depend => they depend upon

✔

> Elm architecture  
> Elm is more like ML than Haskell  
> Defer mentioning higher-order/cyclic streams till later when you define them.  
> Instead: “user interfaces are inherently a cycle of alternating input and output, which is reflected in the Elm architecture”

✔

> Reflex
> Show the types of button and display

✔

> Note how the do notation is implicitly assembling the view as if by accumulating side-effects from button and display, unlike the explicit construction in Elm.

The view is very explicitly assembled in Reflex - the vertical order of statements is the explicit order of the view. The "side-effects" we get from `button` and `display` are their event streams, which are also explicit. It *is* unfamiliar to use `do`-notation to construct an event propagation network, instead of how it's normally used for imperative code, but that doesn't make this code imperative.

> Is it easy to hierarchically compose views in Reflex?

✔

> delete “we here”

✔

> The price we pay for this explicitness is that events are abstracted from the single values in Elm into a time-stamped stream of values. In Elm we write a global state reducer function that pattern matches on these events. In Reflex we use stream combinators to define the model and view as streams of values of each other. The single global I/O cycle of Elm becomes a number of cyclic definitions between model and view streams in Reflex.

  ✔

> Diagrams  
> Finding them a little hard to understand. The top level is the big yellow boxes, but what exactly are they?   
> Categories of some sort? I’d expect the top level of the Elm diagram to be Model, View, and Messages.  

This is a great question. I think this makes it clearer:

<iframe src="https://mermaidjs.github.io/mermaid-live-editor/#/view/eyJjb2RlIjoiZ3JhcGggVERcblxuc3ViZ3JhcGggdmlld1xudmlld0lucHV0Qm94XG50b2RvQ2hlY2tib3hcbnRvZG9JbnB1dFxuYWN0aXZlQnV0dG9ue2FjdGl2ZUJ1dHRvbn1cbmNvbXBsZXRlZEJ1dHRvbntjb21wbGV0ZWRCdXR0b259XG5hbGxCdXR0b257YWxsQnV0dG9ufVxuZGVsZXRlQnV0dG9uXG5jbGVhckNvbXBsZXRlQnV0dG9uXG5jaGVja0FsbEJveFxuZW5kXG5cbm9sZE1vZGVsLS0-dmlld0lucHV0Qm94XG5vbGRNb2RlbC0tPmNoZWNrQWxsQm94XG5vbGRNb2RlbC0tPnRvZG9DaGVja2JveFxub2xkTW9kZWwtLT50b2RvSW5wdXRcbm9sZE1vZGVsLS0-YWN0aXZlQnV0dG9ue2FjdGl2ZUJ1dHRvbn1cbm9sZE1vZGVsLS0-Y29tcGxldGVkQnV0dG9ue2NvbXBsZXRlZEJ1dHRvbn1cbm9sZE1vZGVsLS0-YWxsQnV0dG9ue2FsbEJ1dHRvbn1cblxudmlld0lucHV0Qm94e0lucHV0Qm94fSAtLT4gQWRkXG52aWV3SW5wdXRCb3h7SW5wdXRCb3h9IC0tPiBVcGRhdGVGaWVsZFxuXG5zdWJncmFwaCBtZXNzYWdlc1xuRGVsZXRlQ29tcGxldGVcbkRlbGV0ZVxuVXBkYXRlRmllbGRcbkFkZFxuQ2hlY2tBbGxcbkNoZWNrXG5FZGl0aW5nRW50cnlcbkNoYW5nZVZpc2liaWxpdHlcblVwZGF0ZUVudHJ5XG5lbmRcblxuICBjaGVja0FsbEJveHtjaGVja0FsbEJveH0gLS0-IENoZWNrQWxsPkNoZWNrQWxsXVxuXG4gICAgdG9kb0NoZWNrYm94e3RvZG9DaGVja2JveH0tLT5DaGVjaz5DaGVja11cbiAgICBkZWxldGVCdXR0b257ZGVsZXRlQnV0dG9ufS0tPkRlbGV0ZT5EZWxldGVdXG4gICAgdG9kb0lucHV0e3RvZG9JbnB1dH0gLS0-IFVwZGF0ZUVudHJ5PlVwZGF0ZUVudHJ5XVxuICAgIHRvZG9JbnB1dCAtLT4gRWRpdGluZ0VudHJ5PkVkaXRpbmdFbnRyeV1cblxuIFxuXG5cblxuQWRkPkFkZF0tLT51cGRhdGVcbkVkaXRpbmdFbnRyeS0tPnVwZGF0ZVxuVXBkYXRlRW50cnktLT51cGRhdGVcbkRlbGV0ZS0tPnVwZGF0ZVxuQ2hlY2stLT51cGRhdGVcbkNoZWNrQWxsLS0-dXBkYXRlXG5VcGRhdGVGaWVsZD5VcGRhdGVGaWVsZF0tLT51cGRhdGVcblxuXG5cbiBjbGVhckNvbXBsZXRlQnV0dG9ue2NsZWFyQ29tcGxldGVCdXR0b259LS0-RGVsZXRlQ29tcGxldGU-RGVsZXRlQ29tcGxldGVdXG5hY3RpdmVCdXR0b257YWN0aXZlQnV0dG9ufS0tPkNoYW5nZVZpc2liaWxpdHk-Q2hhbmdlVmlzaWJpbGl0eV1cbmNvbXBsZXRlZEJ1dHRvbntjb21wbGV0ZWRCdXR0b259LS0-Q2hhbmdlVmlzaWJpbGl0eT5DaGFuZ2VWaXNpYmlsaXR5XVxuYWxsQnV0dG9ue2FsbEJ1dHRvbn0tLT5DaGFuZ2VWaXNpYmlsaXR5PkNoYW5nZVZpc2liaWxpdHldXG5cblxuQ2hhbmdlVmlzaWJpbGl0eS0tPnVwZGF0ZVxuRGVsZXRlQ29tcGxldGUtLT51cGRhdGVcblxub2xkTW9kZWw9PT51cGRhdGVcblxudXBkYXRlLS0-bmV3TW9kZWxcbm9sZE1vZGVsLS4tbmV3TW9kZWxcblxuc3ViZ3JhcGggcmVkdWNlclxudXBkYXRlXG5lbmRcblxuY2xhc3NEZWYgcGluayBmaWxsOnBpbmtcbmNsYXNzIHVwZGF0ZSBwaW5rXG5cbmNsYXNzRGVmIG9yYW5nZSBmaWxsOiNmOTZcbmNsYXNzIG5ld01vZGVsLG9sZE1vZGVsIG9yYW5nZVxuXG5jbGFzc0RlZiBncmVlbiBmaWxsOiM0ZmZmNWFcbmNsYXNzIENoZWNrQWxsLENoZWNrLERlbGV0ZSxVcGRhdGVFbnRyeSxFZGl0aW5nRW50cnksVXBkYXRlRmllbGQsQWRkLERlbGV0ZUNvbXBsZXRlLENoYW5nZVZpc2liaWxpdHkgZ3JlZW4iLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9fQ">

> Maybe it would be better to show psuedocode that elides details and add arrows on top to show the interdependencies.
 
This reminds me of Li Hayoi's image: 
 
![](http://www.lihaoyi.com/post/BasicFunctionalProgramming/CodeGraph.png)

Not a bad idea, but I fear it would be even more confusing given that text isn't layed out particularly well for arrows.

> General comments  
> I think it is worthwhile to submit this paper to REBLS. They may say the paper just asks a question without providing any answer, which is left to future work, and so doesn’t make a “contribution”. But they may have so few submissions that they won’t be so strict. In any case it is worthwhile just to get the reviewer feedback. If REBLS doesn’t take it you can submit it to the PX workshop early next year, which would be more likely to accept it, especially if you have made some more progress by then.

This makes me a little sad because of all the work I put into this, but my solace can be that it's the fault of the scientific community for not valuing problem-finding as Alan Kay likes to say.

In a follow up email Jonathan says:

> Definitely [submit this as an] in progress [paper] - they just may not see enough progress. Every submission is a gamble, and everyone gets rejected sometimes, so just go for it.

Encouraging :)

> You could ground the problem of comprehensibility by looking at making changes to the app, for example adding another state affected by the existing buttons, and adding another button that affects the existing state. Those would require understanding 2 complementary perspectives on the system. This may be analogous to the expression problem. If you can make that connection it would really help to draw academic interest; you could title it the “UI Expression Problem”. Very publishable!

I do like this idea of thinking about how we'd make changes to the app! The essay is already so long though... Let me see if I have room after formatting it in a proper way for submission...

And in a follow up email:

> [https://en.wikipedia.org/wiki/Expression_problem](https://en.wikipedia.org/wiki/Expression_problem)  has generated many papers. Tying into a famous theme like this is a great formula for publication: it shows you are a member of the club, and gives the reviewers an instant image of what the paper is about.

I don't think my paper has *that* much in common with the Expression Problem, which seems to be about code compilation and types.

> The paper does a good job of scaring me off Reflex! “hell on earth”. I’d rather have an IDE tool that lets me keep the simpler semantics of Elm and shows me the interdependencies via static analysis. If that were possible it would be a good research result and might even get used by Elm programmers.

This is a fascinating point. And it may be possible in Elm because modifying records can only be done with static keys, so we can determine exactly which messages modify which pieces of state, and which view elements depend on which pieces of state and emit which messages. However, this would not be as straightforward in JavaScript (and Redux or VueX) given that you can access objects with dynamic string keys, so it'd be difficult to be sure what's accessed and modified where.

Author: Steve Krouse