David Abrahams wrote:
Joel de Guzman <[EMAIL PROTECTED]> writes:
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.
You must've missed that I was talking about a "simplified dynamic
Karma". See below:
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.
Pretty much the same reason why I would prefer writing Spirit
parsers to parse my input than using a general purpose
programming language.
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. 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.
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.
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.
Sounds good! Thanks!
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
-------------------------------------------------------
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
