I often find myself needing to wrap little pieces of code into a whole "object" (programming element or value), sometimes with a name. I feel the same kind of lack as an FP programmer having to code in a language without function "objects"; and indeed the situation is very similar. The cases where i need that in fact follow a schema, let's call it "event". In games, an event is usually something that happens in a particular situation: there is a logic like situation --> happening, an event is in fact the binding of 2 elements. We find something similar with automation (which also is event-driven) sequences: a tree of stages which are reached under a condition and each command a given action: condition --> action. More generally, one may find a kind of cause --> effect schema. An event can be conceptualised as a {cause effect} pair. But what are the pair's elements? And how to encode them in a program? monster'appears : Event{ cause : and monster.is'hidden (= character.pos (33 99)) effect : monster.move 37 101 monster.groar 'fiercefully monster.is'hidden :: false character.scream } The cause is conceptually a logical expression; but it can be arbitrarily complex --thus may require multiple statements if only for readability, also for debugging or other "meta" needs. Otherwise, it is like a proper function, with an output (here a logical value) and no effect. But it does not take any input! instead, any pieces of data it uses are present in the surrounding scope: they _must_ be there, if i may say by logical necessity. The effect is an action, like a procedure that changes the world and computes no product. Similarly, it takes no input but finds its data in the outer scope. Thus, we have 2 kinds of input-less procedures. Otherwise, the notion is somewhat like Ruby blocks I guess. This is also similar to the recently proposed "inline" functions on python-ideas (reason why cc to this list). There may also be a relation to dynamic scoping, since such code segments in fact appear to take their input from the caller's scope: but it is not a _caller_, instead a kind of surrounding block and scope, like in case of inlining. I think _this_ kind of semantics, similar to inlining, is the actual value of dynamic scoping, and what we may miss with static scoping only and ordinary procedures only. We may need a way to have "reified" blocks of code executed in the surrounding scope as if they were explicitely written there, or inlined (or C-like macros). Actual functions/procedures would be overkill, since there is no stack frame (or similar), thus all the typical "prologue" and "epilogue" of procedure calls is unneeded. We just need to jump there, wherever the code lies in memory, and come back. Or, inline à la C, or like C macros, but this in my view does not match the semantics. What I'm considering is code segment "objects" like procedures but without: 1. input variables, 2. local scope, 3. call/return [0], three related points in fact. Even more generally, one may note ordinary "functions", in mainstream langs and FP alike, combine a number of properties, the ones listed above plus: 0. more basically, general notion of a block of code as programming element 4. in addition, possible output product, for a function-like code segment (maybe I miss some) For the present notion of code segments, all i need is 0, plus 4 in some cases. [2] I'm not sure at all this is a good idea, however --but I like it and would regularly use it if available. d [0] With register save, new stack frame construction, param passing (prologue), etc, and undoing of all that. [1] A static location would not be thread safe; the only other possibility I can think of is dynamic allocation on the heap: overkill. A real alternative is _not_ passing the product back, but noting that at a low level, there are no functions, instead only actions that write somewhere. Eg: x := DIV y z actually means: DIV x (y z) (and in fact at an even lower level x is y, so we get "DIV x z") Similarly, when part of a higher expression we need temp storage location, eg: a := SUM b (DIV c d) requires: DIV temp (c d) SUM a (b temp) Also: IF (EQUAL a b) THEN do-that gives: EQUAL temp (a b) IF temp THEN do-that Function-like code segments would take the place of explicit expressions here. For instance: a := segment-name a := SUM b segment-name if segment-name then do-that Thus, a rewriting rule can get read of their output altogether, I guess. [2] Detail: in a low-level language, it may be easy to do that: a pair of goto; but the instruction for jumping back must accept a _variable_ target, and the the forward one may also be variable at times. In assembly, it's jumping to given addresses, or even just setting the PC register (program counter); there is no issue of variable targets at this level, they're variable adresses in general, meaning pointers. The only issue is scope restriction on such jumps (whether and how to possibly jump into other memory segments). A final point is the output of function-like code segments: we may need a single, temporary stack slot for it [1]. All these issues are solved for ordinary procedures.