-
@rsnous Yeah, I have a couple of things tho throw out there: The system needs to also establish the identity of the call-context to track it's "lifetime". E.g. for react, component-render-invocation is done by react, so react also knows when to free up the resources allocated for each fnPermalink On twitter.com
❤️ 2 Favorites Mood +2 🙂
-
@rsnous the "hooks" (in react talk) need some special sauce to talk to the global state management system and learn about the "fully-qualified state name", so there's special implementation details. But once you have basic hooks they compose trivially w/o this as functions!Permalink On twitter.com
-
@rsnous This really makes it work in react. You can write something that looks and feels like a native hook, but really it just a function that calls a bunch of other hooks. Anyone who can use hooks and write functions can produce these, without knowing the render and identity internalsPermalink On twitter.com
-
@rsnous What react *doesn't* take to the max in this pattern is the identity tracking itself. In react there are some rules about hooks: inside each component-instance, over time, you need to: - always call the same set of hooks - in the same orderPermalink On twitter.com
-
@rsnous this is because they identify hook calls by integer indices. If they used explicit naming this constraint could go away*. *It opens up the question of what happens to state that is unused for one invocation, is it reset/freed immediately? That probably makes the most sense.On twitter.com
-
@rsnous If you control the language itself, there may be no need for either: the AST already uniquely identifies each hook invocation. This is what I'm doing with alv. I think it could also be done with Lisp macros, but it might be complicated / want to permeate the whole languagePermalink On twitter.com
-
@rsnous With explicit labelling or smart AST-labelling you get full control flow, not just conditionals: [num, setNum] = useState('c', 0) for (i : 0 .. num) { [val, setVal] = useState('v'+i, ''); // render input field (val, setVal) } // render "add" button (setNum num+1)Permalink On twitter.com
-
@rsnous With react I have a love/hate reaction to the hooks thing, especially the dependency management/optimization part makes me a bit weary of the design being shoehorned in through function calls.Permalink On twitter.com
-
@rsnous Thinking about alternatives... the core feature really just is state, so a language could provide just that as a native feature: C-like "local static" variables, but with an identity that is tied to the "invocation identity" not "definition identity" of the functionPermalink On twitter.com
-
@rsnous i.e. in C int counter() { static int c = 0; return c++; } returns the next number every time it is called, but it cannot be used to generate the series (0, 2, 4) like this: int doubles(){ return counter() + counter() } ...because both counter() calls share their "c" statePermalink On twitter.com
-
@rsnous Again all the identity tracking stuff would have to be done by the language. Essentially the state of a function should be tied to stack-trace at the time the function is invoked.Permalink On twitter.com
-
@rsnous But the stack would also have to contain loop identifiers, and the user should be able to control these, like the react "key" meta-prop to give stable identity to values in sequences. But if implementing persistent state like this, why not persistent identity in general?Permalink On twitter.com
-
@rsnous Oops, I just reinvented OOP.Permalink On twitter.com