I try to. I've given examples, comparisons with existing frameworks, technical and design details, etc. but it's hard to explain clearly because it's an API which is designed to abstract things. And the abstraction itself is meaningless without modules, and there is no module right now (I'll talk more about this below). So you have to use your imagination, or simply give your opinion about the examples that I've already given, which are clear enough I think.
Again. If you know this, why not be clear about what your work is and is not capable of?
Macros would add even more verbosity because the lack of templates and overloading. If you look at boost.mirror, which is entirely based on macros, it's kind of ugly actually.
The protocol you've developed is not practical because the additional burden on the developer. You need to alleviate this burden if you want this to be widely acknowledged. As much as I hate implementation macros, I feel this protocol could be improved with additional macro facilities to reduce repetition and the initial burden.
The only thing that would ease the work of the developer is a precompiler, which is not incompatible with CAMP like I said before.
Indeed. CAMP now needs to be enriched with common modules (see below).
I'm not even sure how this library alleviates the issue. As far as I can tell, it only supports a few trivial primitives ("dumb string"). You'd still need to code the necessary compatibility layer the API for the embedded language interpreter expects. I suppose, in the fullness of time, new primitives for popular projects may be available.
It depends. It's currently not supported but it could be. It would be limited to script languages, but it could be useful.
I imagine that also applies to other facilities that "vanish" like operators, function overloads, and variable argument functions?
About the modules
This is the main problem in my opinion. Right now we only provide the core API so that developers can declare metadata, but there's nothing that you can do with it without some extra work.
But now that the core library is stable enough, and that the website and the forum are ready, we'll focus on writing such modules:
- a CAMP-specific precompiler
- a GUI object editor
- a Python module
- a Lua module
- a XML module
- anything that people might find useful
- ... plus all other modules written and shared by the community
The philosophy of CAMP could be "bind once, use everywhere".
So you'll soon be able to get all these features for free if you use CAMP. And with the precompiler it is even more free.