2009/3/12 Michael FIG <[email protected]> > My story for backtracking is that any rules that may be backtracked > don't output directly to the stream, rather they record their output > in a buffer until there's a commitment
This is where backtracking grammars and nested transactions (e.g. STM) intersect in a really interesting way. Each alternation acts like a nested transaction, with the different branches glued together with the orElse operator (a la Haskell's STM monad). When one branch fails, it invokes the retry operator. ( http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/stm.pdf) So let's say you make your append-to-output-stream operation transactional, just like the read-from-input-stream is already in OMeta. You could glue together the two cooperating concurrent programs by letting the transactions from the earlier program in the pipeline flow on into corresponding transactions in the later program in the pipeline. When the earlier program decides to rollback a (nested) transaction, it tells the later program about it, which causes an abort of the speculative branch of work the later program was engaged in. When the first program finally commits its way all the way out of the outermost alternation (= the outermost transaction), so does the second (and consequently any further stages in the pipeline), and every stage is in a position to say definitively what their parse resulted in. In short, the communication between the two programs would be messages about *speculative* output (and about begins, commits, and rollbacks), not messages carrying *committed* output. Regards, Tony
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
