Don't quote me on this, but regarding the "open vs. closed" tradeoff, I think the issue relates closely to the expression problem - therefore, we could use a solution to that in order to recover the openness. Again, don't quote me, but I think this could be achieved (in Haskell, at least) using a typeclass with an associated data type. That way you can create instances of the class "SerializableFn" where you must provide a Data type for each instance and a mapping function to/from said data type cases to the appropriate function/s relevant to that instance. That way - whilst you still need to update the code to handle the new case of course - any old code that just uses the typeclass will have the changes propagated automatically; the same way the definition of (+) itself doesn't need to be modified for each new instance of Num a. Not sure whether this would be able to work out with the kinds, or regarding (multiple) type variables, but it seems somewhat promising. I have a feeling the Haskell MemoTrie library and associated paper "Memo Functions, Polytypically!" may bear some relation.
Nat <: nat , so how influenced is this from Russell's type theory? Also you can't derive subsumption rule when row type instantiated Jury is still out on, if 0 is nat
I just want to say this technique is obnoxious. Pretty much the whole point of the this technique would be to apply it to the task of iteratively walking through a tree structure and accumulating a value from it. When this gets brought up on the internet, its always (like this video) walking through a tree structure and NOT accumulating a value or, like other articles, accumulating a value from a sequence structure (like summing a list). Table stakes for this technique to be useful is walking a tree AND accumulating a value - but once you do that, the method shown here just doesn't work - why? because you have 2 different conceptual stacks to maintain (one to maintain position in the tree and one to accumulate the value) and the inlining no longer works the same way and there is just nothing out there that bridges the gap.
Correct! Talk is kind of misleading. The reason why the tree traversal function prints the traversal path instead of returning it as a list is because it CAN'T accumulate the path and return it.
@@1210divs That's not true! As TJ above mentions, you can accumulate a value like a list through a tree using this technique. The things you end up accumulating together are just represented by functions arguments for the continuation.
I watched this talk for the first time around when it was delivered, when I was first properly getting into FP. Even given that, I've watched it at least three times in the past three months. It's just so fun.
'I have to get back to Science...' <3 the music was cool af tho the code could watch out for timing 'errors' in the human's playing too perhaps to derive micro timings?
