On Tue, Dec 13, 2011 at 02:34:00PM -0700, Jon Rafkind wrote:
> I am planning on supporting global state in my peg generator. The way Rats!
> does it with transactions looks pretty good to me but my question is how to
> actually implement the state operations in a manner that work with
> transactions. Specifically the state has to be pure in some sense so that it
> can be "undone" by an abort operation.
>
> My first naive idea is to have some State class (maybe defined by the user)
> with a pointer to a child State class. The start() method of a transaction
> would create a new State object and set parent->next to it. Then the user can
> modify the new State object. commit() would be a no-op and abort() would
> reset the parent->next pointer to null.
For global state you have two options
1. Don't use memoization
2. Say its programmers responsibility
I didn't come up with easily implementable way how combine memoization
with global state.
First try separate memoization table for each state change is most of
time slower than without.
I could do better if I could get alias analysis of whole program to
determine what actualy happens.
>
> In psuedo-code
>
> start(){
> state = new State();
> current->next = state;
> return state;
> }
>
> abort(){
> current->next = null;
> }
>
> commit(){}
>
> # blah = a b c
> # | d e f
> rule_blah(){
> # For each production, do a start/commit/abort sequence
> state = start();
> rule_a(); rule_b(); rule_c();
> commit();
> return
> fail: # if any of the rules failed somehow
> abort();
>
> state = start();
> rule_d(); rule_e(); rule_f();
> commit();
> return
> fail:
> abort();
> }
>
> _______________________________________________
> PEG mailing list
> [email protected]
> https://lists.csail.mit.edu/mailman/listinfo/peg
--
We're out of slots on the server
_______________________________________________
PEG mailing list
[email protected]
https://lists.csail.mit.edu/mailman/listinfo/peg
