[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall wrote:
> which raises the other issue - a fsm controls something - ie some
> states have effects - i presume you have a list of states and desired
> effects that you want to plug into this fsm - but then yacc should
> still be able to do that....
Tim Bray kindly sent me his DFA spec that he used in Lark. Tim has also
now made his version available to the public, see his
www.tbray.org/ongoing website or planet.xmlhack.com
I have made an XML-syntax version of this: if Tim OK's it I will make
that public shortly--I am checking it against the corrections to XML 1.0
and against XML 1.1. It should be a really good headstart to anyone
wanting to experiment with parser design issues. You could use XSLT as
the proprocessor to generate the code. Actually, there are still
platforms which don't have strong XML processors available (or not open
source ones): I was hearing of a home-made one written for PR/I systems
using EBCDIC 2 weeks ago for example.
Tim's spec does has various triggers for states and assumes some kind of
stack: whether it is implemented using an actual pushdown automaton or
some other arrangement with a stack is up to the implementer.
Tim's implementation does not separate tokenizing and parsing really,
except for keywords: consequently his DFA for DTDs is quite complex. I
think a two level approach (e.g. tokenize "(" "#PCDATA" "|" "b" ")" "*"
in the DFA and then have some higher PDA to parse these tokens into the
declaration components) would be neater, but not faster. And it would
have added to the complexity: if you have a tbale-basd system, you may
as well use it to the full.
Cheers
Rick Jelliffe
|
