Lambda the Ultimate

(This is about semantics in a programming language for creation of responders.) I've been thinking about something off and on recently, and I wonder what the name of this idea is within the context of PL (programming language) terminology, if there is a standard name. If there's not a conventional name, I wonder if it resembles anything else. Also, if the idea itself seems incoherent, or inferior to a better way of looking at it, I'd like to hear that too.

When we write code to pragmatically do something, it calls an interface that already exists, that is already established, which is ready to respond to such invocation. At a given moment in time, some number of callable functions exist in a current process, as well as executable programs in an operating system context, and reachable servers over comm systems (of which networking is a subset). Tools at hand willing to respond to new uses thus offer affordances for latent services that can be invoked. System design includes arranging affordances you need for an app will exist at runtime, and bringing up a complex system — when it starts — typically involves carefully ordered initialization so components are ready before actual first use, or can lazily wait until a service is ready.

The idea I'm thinking of is related to boot-strapping, but that idea often refers to traversing a well-known path known statically ahead of time: getting from start at A to everything ready to go at B, where A and B are pretty much the same most of the time. I'm interested in how one plans a programming language or app framework (etc) so the concept is explicitly addressed by the tools, so there's a way to talk about designing points A and B in time, within a programming language for example. It's related to both compile-time build processes as well as runtime data structure creation necessary when a program starts before some operations can be supported. If servers and other actors are launched and wait to handle messages and connections, it's also about language used to describe timing, types, and semantics of such behavior.

If you write an app with a virtual file system, a configuration phase that mounts resources where they can be found by clients later is also under the same semantic umbrella. Managing namespaces in general, and actually creating bindings at runtime are also semantically related. So module systems in a programming language touch part the same topic, if the element of time is explicitly handled. Managing dynamic evolution of binding systems in time is the part I want a sub-lexicon of terminology to address, rather than devs merely assuming an implicit common understanding no one ever talks about. (It's hard to bring language tools to bear on things never encoded.)

I know Erlang has conventions for managing restart of processes that fail, and that sort of thing. Is there a larger practice outside Erlang that gives names to elements of service management? Best would be terminology that is applicable at all times during programming execution, and not just launch, so it's easy to talk about stopping and restarting embedded sub-systems without terminating host operating system processes, with jargon re-usable outside just one framework. Every time you think of another word that gets used to describe part of such processes, I might find it useful, so even short posts mentioning specific words is helpful.

My point in posting here? It seems reasonable for a programming language to be able to write specifications for time dependent behavior of bindings visible when starting and stopping visibility of callable entities with dependencies on one another. I suppose I could re-purpose terminology used for a narrow context for use in a more general way, but that easily confuses people.

Does anyone know of any work where HM-style type inference is performed at run-time rather than compile time? By this, I mean unification with type variables dynamically using precise (run-time) types.