[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ANN: Amara XML Toolkit 0.9.0
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|