[
Lists Home |
Date Index |
Thread Index
]
On Thu, 2004-12-23 at 09:40 +0000, Michael Kay wrote:
> Interesting. We seem to be rediscovering co-routines, plus a lot of other
> machinery from Jackson structured programming.
Don't say that if there are any Scheme or Haskell hackers hanging about.
They've been using co-routines for an age (I first met the idea in
Scheme).
I think that full co-routines wouldn't do all that much to simplify SAX
processing over my semi- approach, but full continuations would blow the
doors open on the possibilities. Guido found that continuations are not
practical for Python without major architectural change, but this may
change.
It would be interesting to see what sort of XML processing paradigms
people might cook up in Stackless Python [1], a variant of the language
with true continuations, and thus also co-routines and microthreads as
well as generators.
> It's a powerful solution to
> the push-pull dilemma, but it does need support at the programming language
> level (because the process has multiple stacks). I tried to do something
> similar in a very early version of Saxon, but it relied on Java threads and
> became very unwieldy.
Yes. Simulating co-routines with threads is extremely unwieldy. That's
why I and others were very excited when Python got generators at the
language level. Generators are powerful enough as they are, and with
generators, you can readily have semi-co-routines and microthreads.
> Of course if you move to a higher level of programming (say XSLT or XQuery)
> then the push-pull decisions, and the mechanisms used to handle push-pull
> conflicts, get hidden under the covers and programmers don't need to worry
> about them.
Well, for one thing I've already mentioned what a seeming majority of my
Python colleagues think of the likes of XSLT and XQuery (I think I've
heard words such as "abomination").
Secondly, there is no substitute for native programming language support
in many real life scenarios, so I'm glad that I can help Pythoneers
avoid some of the mess at either extreme end of push/pull. Java has its
own data bindings and the like in order to give programmers more bare
metal in XML processing, but I think that many characteristics of Java
make these very inflexible beasts (I tried studying some for ideas with
very little to show in result).
Aside: I've heard that upcoming versions of C#/CLR are looking to
provide similar exotic flow of control constructs. I'll have to watch
Oleg Tkachenko's blog for more on such developments and how they affect
XML processing in .NET.
[1] http://www.stackless.com/
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html
Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-xml.html
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html
Use Universal Feed Parser to tame RSS - http://www.ibm.com/developerworks/xml/library/x-tipufp.html
Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/
The State of Python-XML in 2004 - http://www.xml.com/pub/a/2004/10/13/py-xml.html
|
