Dave Abrahams wrote: > 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.
This essentially comes down to where in the QuickBook processing you want to run the extended functionality. The current implementation is a good QuickBook -> DocBook translator. It currently provides basic transformation and manipulation facilities via macros and the new template feature. What you are wanting is the ability to hook into the QuickBook processor as it is transforming the document and provide powerful scripting where you need to extend the QuickBook facilities -- sort of like uber-templates :). > 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? ;-) Most people who use Boost, but not everyone. > > 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? You can use BoostBook as the XML format to represent the AST. In that case, you don't need to transform QuickBook to yet another intermediate XML format. > > 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. :) XSLT is very powerful and useful in certain circumstaces, but adds another step in the transformation tool chain. Allowing scripting hooks to output a custom format (defaulting to BoostBook) would allow you to speed up the transformation and produce cleaner native output (do I really want all of the DocBook RTF or HTML output?) > > 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? Yes. With BoostBook, you can post-process the XML after QuickBook. Being able to use scripting hooks/bindings to Python (optionally via a --scripting flag?) would allow more powerful transformations on the source document. As an example, you could embed compressed sections in DocBook and then decompress them in Python. Try doing that in XSLT! - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
