Lambda the Ultimate

I'll summarize parts of the paper I grasped, then note how it relates to something I'm pondering (some kind of theory of affordances).

I gather a talent is a like a per-object class, used for dynamic per-instance behavior extension and editing (including removal of old behavior, likely subverting law of demeter, which I don't mind). In classic Smalltalk, an object sent a message looks for the method in the object's class, so an object's scope of behavior is static if its class cannot change and the class's methods cannot change. Behavior is in the class, and each object has one class (subsuming all inherited classes one way or another), so all instances of an object type have the same class and thus the same behavior.

Adding per-instance object behavior, via one or more talents, alters dispatch to find behavior in the talents as well as the object's class. Methods are in the same namespace so a talent can override inherited class methods, or remove them or rename them. Namespace conflicts among multiple talents are resolved by explicitly disambiguating names, including by name change to an alias. The result is dynamic behavior varying between instances and over time, both. Given instances A, B, and C, if you debug their past behavior you'll have to determine things they could have done at different moments in time, if they briefly had a talent for it.

If you imagine methods known by an object instance as gathered in layers, each layer like a transparency listing methods from a class or talent, then scope of behavior for one instance is whatever it can see in the merged transparencies (but where a layer on topic can edit a lower one). Talents might all belong to one flat layer on top though, without stacking.

Sounds interesting but chaotic: extremism in dynamic typing. I'd hate to debug it, but I like it as a use case for thinking about any system analyzing what can happen.

I have this really half-baked idea cooking in the back of mind, and talents seem tangentially related to the extent they edit affordances. But I'm not even sure affordances is a central aspect. There's a whole bunch of topics, like push-vs-pull and inversion-of-control, that seem related to me at the moment. I think I got started on this train of thought by trying to decide whether all systems were event oriented, if you took advantage of duals to prefer an event perspective in each case. Everywhere a producer and consumer hand off signals, however coded, they had to find each other and be willing and able to rendezvous in a transaction. I was trying to imagine writing docs about what it means when you transform stand-alone programs into lightweight processes, especially if you create pipelines and coroutines. Blocking is like saying, "Send me an event when I can keep going." So you can see where I got the event-oriented focus. I feel like I'm untangling a ball of yarn. Not sure if it's meaningful.