Feed variables into other variables (limit scope of variables)

[Gazook89]

Your idea:

I'm opening this on behalf of a discord user so hopefully I have the request right-- could variables somehow have their scope limited to some degree, such that a variable could be reassigned throughout the brew?

The idea is to be able to do something like this:

[TraitMagicResistance]: The $[Name] has magic resist

[Name]: Sally

$[TraitMagicResistance]

[Name]: Barney

$[TraitMagicResistance]

and get output like this:

The Sally has magic resist

The Barney has magic resist

So the Name variable could be reused within another variable template. To more precisely show the thinking of the requesting user, the TraitMagicResistance could take in another variable to fill slots, like this:

[TraitMagicResistance]: The $[Name] has magic resist

called like this

$[TraitMagicResistance][Sally]
$[TraitMagicResistance][Barney]

And I suppose with this latter syntax the trailing variables would just fill in from beginning to end if there were multiple. Sort of like regex The $1 has magic resist substitution.

[ericscheid]

I anticipate that sometimes authors will want a variable insertion to occur dynamically, and other times will want the value captured as at time of declaration.

[calculuschild]

Wasn't this already discussed pretty heavily when designing the specs for variables? I feel like we decided to avoid this exact thing for a specific reason, but I can't recall at the moment.

In any case, something like this would involve basically a full rewrite of the Variables extension. I would put this at low priority for now.

[ericscheid]

Done for two main reasons: 1) to avoid recursion hell, and 2) to facilitate imperative interpreting.

Both are still good reasons.

The functionality suggested by $[TraitMagicResistance][Sally] shouldn't even involve further varnames. As Gazzok89 suggests, the functional form declaration should be more like [TraitMagicResistance]: The $1 has magic resistance. .. where the $1 represents to first fed-in parameter. This way each parameter can be re-used in the same template too, like $1 and $2 were sitting in a tree. $1 was hopeful, $2 not so much. $3 observed from a distance.. (The syntax suggested here is only a placeholder).

Whether these are called template variables, or madlib variables, or function variables .. eh, whatever works.

In any case, I agree .. we should let variables sit for a while before attempting to extend it. Let the bugs shake out. And remain open to a possible rewrite as a solution.

[Gazook89]

Yeah, I felt this was likely discussed heavily but I just couldn’t point to where, and I wasn’t really involved in variables discussion (by choice).