|XML Parsers (Push and Pull) firstname.lastname@example.org (2002-01-18)|
|Re: XML Parsers (Push and Pull) email@example.com (Bill Rayer) (2002-01-24)|
|Re: XML Parsers (Push and Pull) RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-24)|
|Re: XML Parsers (Push and Pull) firstname.lastname@example.org (2002-01-28)|
|Re: XML Parsers (Push and Pull) email@example.com (2002-01-28)|
|Re: XML Parsers (Push and Pull) firstname.lastname@example.org (2002-02-06)|
|Re: XML Parsers (Push and Pull) email@example.com (2002-02-16)|
|Re: XML Parsers (Push and Pull) firstname.lastname@example.org (2002-02-28)|
|Date:||6 Feb 2002 23:33:08 -0500|
|Posted-Date:||06 Feb 2002 23:33:07 EST|
Well, ... as long as we are ad_hoc_ing it, perhaps it is relevant to
suggest a modern UNIX iostream as a useful paradigm, as being
something beyond mere push versus pull.
An iostream conceptually is illustrated well by an IP stack, wherein
distinct functions reside in disting layers arranged in a kind of
chain. Most IP stacks can handle bidirectional flow. In lexer-parser
context, a lexical 'state' change is like a blow back from the parser
to a lexer.
Indeed, most IP stack arrangements, implemented as UNIX iostreams or
not, allow for a flow of control messages distinct from the data
content messages (and these too in either direction).
Such a paradigm offers a different point of reference for error
handling. The key is that the notion of compiler-state and IP stack
state are not exactly the same.
Built into the compiler-state notion is this transparent hierachy, in
the midst of which we are coursing at any given moment. XML violates
this notion into oblivion by simply stating that errors are not
allowed! Which is useful (and obviously reasonalble considering most
of this sort of markup is machine generated).
So, ... although it might at first seem a startle, the bidirectional
stack idea, or as a previous poster penned, the idea of co-routines,
might be a useful reference for designers of XML lexer-parsers.
XML deprecates the central element of the fragility of the ongoing
hierarchy of your parsed input by simply saying that it can not be
Going beyond simple lexing and parsing, one contemplates the style
sheets and the query standard evolutions as new inhabitors of an
execution space that has more than merely two co-routines. The flow
lines could get intricate. But, hey, why not, if syntax errors are
crater time! Just unplug everything when in trouble, ... sync, sync,
sync ... then halt your parse.
Return to the
Search the comp.compilers archives again.