Joel de Guzman <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> >> 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. > > Pretty much the same reason why I would prefer writing Spirit > parsers to parse my input than using a general purpose > programming language.
In other words, IIUC, you prefer using a language that's suited to the domain. But your semantic processing is still done in a general purpose language (regular C++, plus phoenix or whatever other lambda system that is just a fancy reflection of C++). Do you know what a language suited to the domain of extracting and testing code examples embedded in documentation looks like? I don't think it's a very well-understood domain, and I predict that even looking at examples won't be enough to tell us where the limitations on that language should be. >>>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. > > I'm quite aware of that, Dave. Thanks for the reminder. Rest > assured I'm not heading that route. I'm just exploring all > possibilities. At the end of the day, I'll choose the simplest > scheme that sufficiently covers all bases. We are still in the > proposal stage. Okay. > At any rate, I'd appreciate it if you would wait a bit for something > to take shape and form first before concluding that it's no good. I haven't drawn any conclusions other than that I've been unable to communicate to you the complexity and breadth of the domain we're addressing. >>>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. > > Agreed. I am well aware of the power we get by having a scripting > language. If it's Python, so be it. I'm not resisting that idea. > QuickBook will not "sprout it's own scripting language", that's > one thing we can agree on. It's totally against my "keep it as > simple as possible" principle. I understand that it wouldn't happen that way initially. What I'm concerned about is that if we choose something like "simplified dynamic Karma" (as far as I understand what that is), we will eventually find lots of places where it's insufficient. We'll then be faced with a choice of whether to extend it, scrap it, or let it live on alongside something more powerful. The latter two choices have disadvantages you're obviously already aware of. The first is the one that can easily lead it to become a sort of crippled scripting language. Anyway, if what I'm saying gives you no new insight or is just getting annoying, I apologize for harping on it. One last thing: one way to achieve true separation of concerns is to pick a special comment format for literate programming directives as I did, and just be sure to write all the comments into the XML. Then we can write an XML postprocessor (in Python, maybe) that extracts the examples and the directives. Heck, we could probably use most of the Litre source verbatim with a little XML-reading front-end. Then you really don't need to worry about "contaminating" (my word, not yours, I know) quickbook with unrelated things. -- 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
