Rene Rivera <[EMAIL PROTECTED]> writes: > 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.
Sorry, I don't get it. You can always use a Python backend that writes XML and read that in with Lua or PHP as you're suggesting below. It sounds like you're saying that, because someone might be interested in any number of different languages that are superior to C++ for doing this backend work, we should stick exclusively to C++, a language that's inferior for this sort of work. In fairness, my suggestion does impose the requirement to have Python installed, even on developers who aren't interested in Python, but doesn't everybody have Python already? ;-) >> 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. Isn't that just BoostBook? > If the AST format is XML based for BoostBook/DocBook the translation > could still be done with XSLT. You say that like it's a good thing. :) > 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. Isn't that where we are today? -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
