This is a method of caching that requires the parsers to create new cache
slots, evaluate, then invalidate the cache slots when it goes out of scope.
This differs from the InfosetCachedEvaluatable, which caches values in the
infoset and relies on backtracking and removal of infoset nodes to
invalidate the cache.
The Evaluatable implementing this must have an MStack stored in the PState
or UState, and getCacheStack will be used to retrieve that stack. Before
calling evaluate for the first time, the parser must call newCache. All
other calls to evaluate will use this evaluated value. When the evaluatable
goes out of scope, the parser must then invalidate this cache by calling
invalidateCace.
The motivating use case for this is for DFAFieldEV and EscapeEschemeEV.
DFAField is dependent on the escape scheme. The logical way to handle is to
make the EscapeSchemeEv a runtime dependent on the DFAFieldEv. This is
convenient since if the EscapeSchemeEv is constant, we can calcuclate the
DFAFieldEv at compile time.
However, say the EscapeSchemeEv is not constant. The problem is that it
needs to be evaluated in a different scope than when the DFAFieldEv is
evaluated. So this manual caching thing is a way to force evaluation of the
Ev at the appropriate time (via the DynamicEscapeSchemeParser), and cache it
in the PState. Then when the DFAField is evaluated it can use that
cached value. Note that the problem with storing the cached value in the
infoset (ala InfosetCachedEvaluatable) is that the current infoset element
may have changed in between the time the EscapeSchemeEv was evaluated and
the time the DFAField is evaluated. So if we cached on the infoset, when the
DFAField asks for the EscapeSchemeEv, it will look at the currentInfoset
cache and it wouldn't be there, and then evaluate the escape scheme again in
the wrong scope.
This is a method of caching that requires the parsers to create new cache slots, evaluate, then invalidate the cache slots when it goes out of scope. This differs from the InfosetCachedEvaluatable, which caches values in the infoset and relies on backtracking and removal of infoset nodes to invalidate the cache.
The Evaluatable implementing this must have an MStack stored in the PState or UState, and getCacheStack will be used to retrieve that stack. Before calling evaluate for the first time, the parser must call newCache. All other calls to evaluate will use this evaluated value. When the evaluatable goes out of scope, the parser must then invalidate this cache by calling invalidateCace.
The motivating use case for this is for DFAFieldEV and EscapeEschemeEV. DFAField is dependent on the escape scheme. The logical way to handle is to make the EscapeSchemeEv a runtime dependent on the DFAFieldEv. This is convenient since if the EscapeSchemeEv is constant, we can calcuclate the DFAFieldEv at compile time.
However, say the EscapeSchemeEv is not constant. The problem is that it needs to be evaluated in a different scope than when the DFAFieldEv is evaluated. So this manual caching thing is a way to force evaluation of the Ev at the appropriate time (via the DynamicEscapeSchemeParser), and cache it in the PState. Then when the DFAField is evaluated it can use that cached value. Note that the problem with storing the cached value in the infoset (ala InfosetCachedEvaluatable) is that the current infoset element may have changed in between the time the EscapeSchemeEv was evaluated and the time the DFAField is evaluated. So if we cached on the infoset, when the DFAField asks for the EscapeSchemeEv, it will look at the currentInfoset cache and it wouldn't be there, and then evaluate the escape scheme again in the wrong scope.