> K also has a the concept of dependencies and triggers. They are used for efficient, demand-based calculation of data and executing callback code whenever a value is changes (this is how the timer system in K works). K will keep track of out of date dependencies for you and only do the minimal amount of work necessary to update values.
This seems powerful. Is "doing the minimal amount of work" provably true, or is this just a way of saying that it's usually fast?
For example, let's say that I have a list of numbers that I have sorted using bubble sort. Now I change one of the numbers. Would the update be O(log N)?
> K has a unique, declarative GUI subsystem that is based around the K tree and triggers. It takes a minimal amount of work to put a GUI on your application. K takes the approach that you show variables and changes made to that variable on the screen are immediately reflected in the program without any work by you.
This sounds like Svelte avant la lettre. I'm really curious how the updates are performed.
> This seems powerful. Is "doing the minimal amount of work" provably true, or is this just a way of saying that it's usually fast?
It is powerful, it's not provably true (or even generally true ...)
"Dependencies" are Excel-style recomputation. The code c::a+b says (1) that c depends on the value of a and the value of b, and that (2) whenever you evaluate c, if 'a' or 'b' has changed since the last evaluation, you re-evaluate the expression and assign it to c; otherwise return the cached value. So, multiple changes to a or b will not trigger recomputation - only the eventual use of C; However, it's possible that 'a' is a vector of length 1,000,000 and so is b, and only one element in a was changed - K would still do a million addition operations.
"Triggers" work the other way arround: You used to set a trigger on 'a' by assigning a trigger function a..t:{[d,i] ...} which would receive as argument the post-assignment value 'd' and the indexes assigned 'i'; You could use these to do a minimal update of whatever logically depends on a; However, the triggers DO fire on every change unlike dependencies.
> For example, let's say that I have a list of numbers that I have sorted using bubble sort. Now I change one of the numbers. Would the update be O(log N)?
I think there is no way to guarantee O(log n) anyway in this case - change the first element to be in the middle - requires at least O(n) changes on either a sequential or singly/doubly linked list. But assuming you're talking about say, a heap structure - the answer would be "No" for a dependency, and "If you implement it yourself" for a trigger.
> This sounds like Svelte avant la lettre. I'm really curious how the updates are performed.
Sort of. It was a native GUI, incredibly fast, and incredibly bare bones - it was eventually dropped because all the customers were making web front ends anyway.
Being a native GUI, I suspect (but don't know) it was using the triggers to mark damage regions and let the windowing system take over from there.
This seems powerful. Is "doing the minimal amount of work" provably true, or is this just a way of saying that it's usually fast?
For example, let's say that I have a list of numbers that I have sorted using bubble sort. Now I change one of the numbers. Would the update be O(log N)?
> K has a unique, declarative GUI subsystem that is based around the K tree and triggers. It takes a minimal amount of work to put a GUI on your application. K takes the approach that you show variables and changes made to that variable on the screen are immediately reflected in the program without any work by you.
This sounds like Svelte avant la lettre. I'm really curious how the updates are performed.