David Abrahams wrote: > (in Python of course -- a much better language for ASTs than > C++ because of their very dynamic structure).
Not that I disagree with that. But I think preferring more than one language, I'm counting the C++ implementation, is going to be detrimental to the eventual flexibility of quickbooc. After all I might want to use Lua or PHP, also languages well suited for dynamic nature of ASTs. > The various back-end > translators (also written in Python) are simply SAX-like visitors that > generate "events" for the entry and exit of the various AST nodes. So > when entering the "table" node, the translator's visit_table method > (if any) is called, and when leaving, its depart_table method is > called. > > The code for translating the DOM into HTML, LaTeX, or any number of > other formats they already have support for is surprisingly > straightforward and maintainable. With a system like this, if we > wanted to write a Qbk->Docbook translator in addition to the Qbk->HTML > translator it would be simple. One thought I had yesterday about the backend quandary is to generate a quickbook specific format and have the back ends transform that into the real target format. Basically it's what Dave is suggesting but having an external version of the AST. If the AST format is XML based for BoostBook/DocBook the translation could still be done with XSLT. And hence would be a minimal impact on the current toolchain. For doing a backend on Python, PHP, etc. it would be easy to translate that into an internal AST as most such languages already have libraries for XML->AST parsing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
