Joel <[EMAIL PROTECTED]> writes:
> Joel wrote:
>> David Abrahams wrote:
>>
>>> Joel <[EMAIL PROTECTED]> writes:
>>>
>> Have you looked through the litre examples from CPPTMP yet? I like
>
> Yes.
Do you have a list of examples from CPPTMP that can't be handled
directly in QB using your proposal, yet?
>> the high-level idea here of identifying the replaceable text by name,
>> but it still seems as though you're trying to do too many things that
>> should be left to a general-purpose scripting language. For example,
>> suppose the code snippet needs several instances of true-or-false-type
>> and some of them need to be replaced with different text?
>
>> My goal has always been to be able to do, without resorting to
>> programming, 99% of the task and leave the remaining 1% to
>> scripting. This 99% is exactly what I am trying to identify now.
>> Isn't that a worthy goal?
Maybe. I'm not confident that there is a stable "sweet spot" in this
design space. Even if you hit something that feels good today, I get
the sense you'll be forced into feature creep to keep it useful. I
admit this is 95% intuition without evidence.
>> If John thinks declarative XML is ugly, IMO, compared to XML,
>> imperative scripting is even uglier (regardless of language).
So, all imperative coding in C++ is ugly and really ought to be
replaced by something "declarative?"
>> They obscure the intent of the author and block the natural flow of
>> content which is, I think, anathema to the wiki-wiki concept with
>> its simple and instant syntax. I remember you were concerned once
>> that QuickBook escapes too much to BoostBook and you say "We need
>> to get Quickbook to a point where you don't need to know BoostBook
>> in order to get real work done". I'd say the same thing with the
>> scripting language, once its installed.
>
> I just realized that the use case(s) above can be handled
> nicely by the macro engine once the ability to parameterize
> macros in QuickBook is implemented.
In other words, "once QuickBook macros begin to take on more of what's
required to be used as a general-purpose programming language." ;-)
> Examples:
>
> [def is_void_code(base)[
> struct is_void : public base {};
> ]]
>
> is_void_code(true-or-false-type)
>
> Now, we wish to "collect" this code fragment replacing
> base with mpl::true_:
>
> [collect code_to_test]
> is_void_code(mpl::true_)
>
> Dave mentions a code snippet that needs several instances of
> 'name' and some of them need to be replaced with
> different text:
>
> [def some_code(x, y, z)[
> struct zzz : yyy<x, y, z> {};
> ]]
>
> Then:
>
> some_code(unspecified, unspecified, unspecified)
>
> And for testing:
>
> [collect code_to_test]
> some_code(int, char, double)
>
> I keep forgetting that macros are a powerful mechanism
> for text generation. Case in point is the Boost PP. I think
> that macros alone can remove most of the need for scripting.
Just like PP metaprogramming can remove most of the need for external
code generators?
Using the PP lib may be the best we can do in C++ today, but it sure
can be awful, at the same time.
I'm not 100% sure I know what the right answers are here, but I keep
pressing on this because Iit sounds like you are all too sure that you
_do_ know. I don't think it's that obvious yet.
--
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
