`[<<][ui][>>][..]`
Fri Sep 8 21:26:47 EDT 2017

## doodling

```https://twitter.com/tom_zwizwa/status/906316251559022592

Phil mentions "incremental lambda calculus".
https://github.com/paf31/purescript-incremental
http://www.informatik.uni-marburg.de/~pgiarrusso/ILC/
http://www.informatik.uni-marburg.de/~pgiarrusso/papers/pldi14-ilc-author-final.pdf

Dah I really don't want to read it.  I'm sure the basic idea is simple.
Can I just reinvent it based on the hint that there is something here?
This has to be about the chain rule.

EDIT: Yes, the idea was simple.  There are 4 rules that resemble the
chain rule.  See compsci.txt

Given a function that maps one nested map into another (Erlang types),
what exactly is a diff of a function?

T0 --> f(T0)
|       |
V       V
T1 --> f(T1)

Given any difference of the input, compute the difference of the
output.  Or find the function

(T1-T0) ->  (f(T1)-f(T0))

I have an explicit diff function already.  Can I just "push that
inside" any tree processing function?

Some examples?

T0 = #{ a => 1 },
T1 = #{ a => 2 },

f(#{a := X}) -> #{ a => X + 1}

the map of the diffs is then

{update,[a],1,2} -> {update,[a],2,3}

The key here is really to define the difference / differential in the
ordinary way:

f(T1) - f(T0)
D = -------------
T1 - T0

And give a meaning to "-" as tree diff.

Is it possible to reconstruct the chain rule by making f to be a
composition of functions?

This is Conal's CCC stuff...

It would help to make this more concrete.  Let's fix the
representation for now.  Stick to actual XHTML and represent the
structure as a nested list.

#{ tag => div,
attr => #{ style => "display: block" },
body => #{ id1 => ...
id2 => ... }}

The trick here is to abstract away all the ad-hoc attrib stuff as
well.  E.g. some attributes have inner syntax that also needs to be
mapped to a tree.  Also id attributes are better used as dictionary
keys.

Once this is done, there are only a couple operations, e.g.:

- Moving things around
- Duplication
- Deletion
- Primitive functions

This is not about the primitive functions.  It is about the structural
transformations and how they can be expressed as function composition,
because that exposes the chain rule.

This is what the CCC transformation is about: exposing composition.

So if the solution is going to be the chain rule, what does + mean?

Let's watch Conal's lecture again.  The paper above is a little too
dense for me atm...

There really must be a simpler way.  A difference of two trees is a
list set of changes, where a change is a tag (add,remove,update), a
path and a subtree or leaf.

The derivative of a function on trees is then a function on the
difference setls.

The trick is maybe to see the trees as functions also?

Let's concentrate on the paper now.  Definition of D(u) where u is a
function.

D(x) = dx  (change of x)

Let's "fix" the paper to use a pure functional algorithm.  There are
no "changes", there are only linear functions.

The derivative of a linear function is the linear function, which is
the termination point of the recursion.

This also solves the type error

So the rules, boiled down, are:

- abs:   D( \x -> t )   ->  \(x,dx) -> D(t)
- app:   D( s t  )      ->  D(s) (t, D(t))

for a concrete function, e.g. a projection of a tree into a value
(e.g. a pattern matching primitive:

f(#{a => A}) -> A.

...

Conclusion for now: there is quite a bit of overhead in building up
the primitives.  In the practical cases I've seen it seems much
simpler to map model changes to view changes explicitly without trying
to derive them.  Double work (initial render + diff), but not too bad
in case the changes are not too extensive.

```
`[Reply][About]`
`[<<][ui][>>][..]`