Giving Functions the Power To Create Local Variables

I've added an experimental routine which is sort of a Pandora's box, but... I kind of feel it's where things need to go.

This lets you add arbitrary new variables into the stream of evaluation programmatically. Demo:

make-two-variables: func [name [text!]] [
    let frame: binding of 'return  ; frame of the call to MAKE-TWO-VARIABLES

    ; make variables for the incoming string with 1 and 2 as a suffix
    ; resulting words will have their binding adjusted to the new variables
    ;
    let word1: add-let-binding frame (to word! unspaced [name 1])
    let word2: add-let-binding frame (to word! unspaced [name 2])

    ; set variables to values as a demonstration
    set word1 <one>
    set word2 <two>
]

do [
    make-two-variables "demo"
    assert [demo1 = <one>]
    assert [demo2 = <two>]
]

So this means you can write your own LET-like thing, to declare any number of variables and inject them into the stream of evaluation.

I've gone ahead and done this with the TLS EMIT dialect. So the act of doing an EMIT will effectively do LETs for its labels, that can be observed by ensuing operations. I've also removed all uses of the SET-WORD! gathering FUNCTION. This means TLS is now operating entirely with FUNC.

(As I've mentioned, the plan is that FUNCTION implying gathering will be phased out...ultimately making FUNC and FUNCTION synonyms).

The mechanism behind this is far from perfect. But what it's replacing was--I believe--a definitive dead-end. The big question here to answer is "does this accrual of state represent something the evaluator shouldn't do, even if it can, because it infringes on the concept of a BLOCK! position alone capturing evaluator state". I think we need to review what "dialects using stepwise services" need...and under that review, I believe we will find that prohibiting the class of features that involve accrued state is too limiting to justify the simplicity.

And while the performance tax of these ideas is going to be something to pay, We're not aiming for device driver code... at least not running under the interpreter! Maybe you write tools that help you generate device drivers, but not running them. I'll once again cite the Minecraft cities...:

2 Likes

A post was split to a new topic: Danny