notes-computer-jasper-jasperViewThoughts

• if views are being used so that you can pass a data structure into something that sees only a projection of it, and mutates that, and then you get back not just the projection but the entire mutated structure, then you need a way to lift the function on the projection onto a function on the entire structure. Which means that functions should, when they are actually created a mutated form of the existing data, operate via mutations on the data being passed in, not by creating new data to attach to/replace the existing data with a mutated form.

E.g. if you are trying to add 1 to each negate each item in a list, you want to do:

l[i] = -l[i]

not:

if l[i] == F: l[i] = T if l[i] == T: l[i] = F

or, worse:

x = l[i] del l[i] if x == F: l.insert(i,T) if x == T: l.insert(i,F)

because in the latter cases, whatever metadata was attached to the original data before it was projected into a list of bools to be passed to you has been lost

otoh people want to use case statements. so maybe we just need an operator to tell Jasper that although it looks like we're replacing instead of mutating, that it should count it as a mutation:

x = l[i] if l[i] == F: l[i] = T@x if l[i] == T: l[i] = F@x

x = l[i] del l[i] if x == F: l.insert(i,T@x) if x == T: l.insert(i,F@x)

note that sometimes you'll want to split or merge nodes, too:

x = l[i] y = l[i+1] del l[i] del l[i+1] l.insert(i,(x+y)@(x@+y))

x = l[i] del l[i] if x == F: l.insert(i,T@x) if x == T: l.insert(i,F@x) l.insert(i,F@x)

in these cases, '@' can be read as 'from'. Graphically, it's like a reference, that is, an arrow from one node in the code (here representing a variable) to another.

note that this has to do with lifting, e.g. inverting a homomorphism (or arbitrary function?) to find the inverse image of a node, and also with the 'lineage' of a node thru that homomorphism

--

Need to make sure that the connections between inputs and outputs of the function, and constraints on that, that is used for views, is fully general and is not restricted to only ancestry

Note that this helps with laziness too

---

note that the term 'view' is inconsistent with common usage, e.g. database views

---

Jasper perspectives could be implemented by *monads*

---

the Spreadsheet stuff is similar to Jasper perspectives in that both are related to binding, e.g. binding between DOM and UI in JS frameworks

--

we say we want to be mostly-referentially-transparent, but views are like aliased-variables/pass-by-reference/pointers/bindings-between-variables. So what gives?

actually i think these things are separable. As long as the view is only being used in a subroutine call, and the original is only being used in the caller, and the caller is blocking on the completion of the subroutine, then there is no problem. this is uniqueness typing.

even if the caller is not blocking to wait on the completion of the subroutine (an async call, like a goroutine), we're fine as long as the caller is not accessing the variable with a view until the subroutine is done.

and even if it does, we control/(track this binding in the type system) using the same mechanisms as an aliased/shared variable without views.

so these concerns are separable.

--

jasper views are like generalized slices in l-values, or like the way that numpy maintains slices as separate but bound objects (except that, as above, views and aliasing are orthogonal in jasper)

--