[Python-ideas] code segments

[Terry Reedy]

On 2/20/2014 8:10 AM, spir wrote:
> 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).

This sounds exactly like exec(codestring, globals(), locals()). It is 
exactly as safe as explicit putting the codestring right there in the 
code, without quotes.

-- 
Terry Jan Reedy