David Abrahams wrote:
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?
Which proposal are you referring to? I don't think I have submitted
proposal yet, other than the original draft, which lead to this
discussion.
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.
I do not think that's a problem. If a use case is considered to
be common (often used), then add the feature; if not, then
leave it for the scripting language to handle.
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?"
I don't think that's possible. Even if it is, I don't think
that's practical. Imperative code has its place. If you want
something declarative, then there are enough declarative languages
out there. Haskell comes to mind.
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." ;-)
No, definitely not. It can't. QuickBook macros, like CPP macros
can never replace 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?
Yes.
Using the PP lib may be the best we can do in C++ today, but it sure
can be awful, at the same time.
True. I certainly don't enjoy some of the coding like, ehm, having to
backslash the end of every line; and that macros do not respect EOLs;
and that there are no scopes.
These things *can* be fixed. It might even spur the development of
a better CPP. Fortunately, with QuickBook, our hands are not tied.
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.
I do not have all the right answers yet. What I do know is that
macros are a simple yet powerful text/code generation mechanism.
What I don't seem to understand is why you are so against
alternative (and hopefully simpler) schemes when it is already
clear that there will ultimately be support for python or
some other scripting language as a fall back anyway. QB parametric
macros will be implemented. It is part of the plan since day one.
Support for python will be implemented. So, why are you still
worried?
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
