TRPL

Today we use the DictionaryWorker to implement scoped dictionaries. This allows us to explicitly push/pop state based on specific rules that map to scope processing based on AST nodes.

A classic case here is to implement scoped processing for resources like variables which must be hidden in nested scopes or otherwise temporarily be updated with different state for a nested scope. The problem is that such processing must be implemented explicitly. It isn't especially hard to do, but it is a bit more awkward than is needed.

   <init-rules>
      <rule>deleteDictionary("dictionary_name")</rule>
      ...
   </init-rules>

   <walk-rules>

      <rule>someCondition
         <action>addDictionaryBoolean("dictionary_name", "var1", var1)</action>
         <action>addDictionaryString("dictionary_name", "var2", var2)</action>
         <action>addScope("dictionary_name")</action>

         <!-- this is optional -->
         <action>var1 = initialState1</action>
         <action>var2 = initialState2</action>
      </rule>

... use var1 and var2, changing the values as needed

   </walk-rules>

   <ascent-rules>

      <rule>someCondition
         <action>deleteScope("dictionary_name")</action>
         <action>var1 = lookupDictionaryBoolean("dictionary_name", "var1")</action>
         <action>var2 = lookupDictionaryString("dictionary_name", "var2")</action>
      </rule>

   </ascent-rules>

The point here is to save/restore the state based on specific events occurring, usually (but not exclusively) in walk and ascent rules.

Instead of doing this explicitly, the scoping could be a feature of the variable definition itself, such that we just mark the variable as scoped and somehow associate the scope push/pop with specific rules. Perhaps we retain the addScope() and deleteScope() but otherwise everything else is done for us.