Joel de Guzman <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Joel de Guzman <[EMAIL PROTECTED]> writes: >> >>>David Abrahams wrote: >>> >>>>Joel de Guzman <[EMAIL PROTECTED]> writes: >>>>The main objective was to get some automated testing for the code >>>>examples in our book. Really, that's all! ;-) >>> >>>And my point all along was that this is the domain of bjam. >>>Now, I realize (below) that you need a facility not only for >>>testing, but also for gathering the outputs back into your docs. >> That would be really great, but my system hasn't been configured to >> to >> do that, so I wouldn't characterize that as a requirement. I've been > > Alright. How about if we start with a list of requirements, > or if that's too formal, a wishlist perhaps?
I could walk through every litre directive I used in the book and tell you what each one does so you could make sure you had the capabilities, but I *still* wouldn't be confident that we'd convered all the bases. Each new chapter was likely to come with an example that had new requirements. > I've been playing mind games on the issue and might have some > ideas of my own. I've noticed that a lot of processing has > to do with text manipulation. Yes, some do. But did you notice that a particular example needed some additional compiler flags? > FYI, Hartmut is working on a > thing called Karma which is the reverse of Spirit, where you > have rules that guide the formatting and manipulation of > output. If it's really "the reverse of Spirit," then the rules need to be compiled into QuickBook, and that will be practically unusable. > I think it is possible to have a dynamic ouput processor > that will work on snippets (collectors). It might be possible > to have a simplified dynamic Karma into QuickBook, where Karma > like rules are embedded in QuickBook. I don't understand why it's okay to use Karma but not Python -- which comes with no risk of being insufficiently powerful for any job -- but I think I'm going to stop trying now. > Then, offlist, there was also some discussion about beefing up > QuickBook's macro system. My proposal was to make the macro > system a little more powerful by adding arguments, instead of > plain text substitution. I think this alone could be a powerful > facility for text manipulation. I think you are headed down the road of language "pidgin-ization" described in Todd Veldhuizen's doctoral thesis. This is what happens when people discover that domain-specific (non-embedded) languages are insufficient to quite cover all the jobs they need, and they begin extending them with features that are really outside the domain. > My goal is to reduce the amount of scripting needed to practically > use QuickBook. In as much as "you should not need to know anything > about DocBook/BoostBook in order to use QuickBook", it follows that > "you should not need to know anything about <place-your-favorite- > scriping-language-here> in order to use QuickBook". So call it "QuickBook with the literate programming plugin." Otherwise I fear QuickBook will sprout it's own scripting language(s). At that point, you were better off using a scripting language "everybody" knows. Furthermore, the way Litre allows the C++ translator to inject language-specific primitives like "compile," "run," etc., the user doesn't really need to learn any Python in order to do the simple jobs. With your collectors in Quickbook the user would be relieved of all those stack manipulations so it would be even less to learn. > A scripting language will still be available, sure, but I think that > should be used only as a fallback similar to "escaping" to XML > BoostBook when we really need to. I'll tell you what; you can download the Book sources; in case you've forgotten how I'll send you private email on it. Look through all the Litre directives in the source (just grep for ".. @") and derive requirements from those. If there are any you don't understand, send me an email and I'll try to explain them. Then you'll have a clear idea of how much or little power and flexibility was actually needed for the book, and whether any of what I'm saying makes the least bit of sense. -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
