On Sat, Oct 13, 2012 at 9:53 AM, Larisse Voufo <lvoufo@indiana.edu> wrote:
On Fri, Oct 12, 2012 at 3:05 PM, Doug Gregor <doug.gregor@gmail.com>wrote:
On Fri, Oct 12, 2012 at 6:25 AM, Andrew Sutton <asutton.list@gmail.com> wrote:
Right now I see two ways forward:
1. I implement N3351 in Boost.Contract and Matt implements N2914 in Boost.Generic. 2. Or, I help Matt implementing N2914 in Boost.Generic (and Boost.Contract's requires clause will use concepts defined using Boost.Generic).
Then we all use the lib(s) to experiment with concepts before (re)proposing concepts (and hopefully contracts) for standardization in C++1x.
Experimenting is great. This is why I have Origin (https://code.google.com/p/origin/). I've been experimenting with concepts-as-a-library in various forms since 2009, and it only gets you so far. It's a very helpful if you want to develop a first pass at concepts for a library, and sometimes it pays off if you need to reason about some language feature interactions.
This is an extremely important point: emulating the concepts language feature with a library has its limits. Most of the hard problems with concepts, including the hard problems of making those concepts that we right actually model what we want---involve the type checking of template definitions. That type checking can be simulated with archetypes, but it's very hard to write archetypes that are as picky as what a compiler would come up with. That means that the concepts we write can't actually be validated against implementations, so it's hard to have any confidence in those concepts.
From the standardization perspective, we'll make zero progress until someone gets working on a real implementation. Just having a concept parser + archetype generator (which then instantiates template definitions based on those archetypes) would be a huge win.
This is intriguing. Based on my current experience with ConceptClang (and I could be missing something), I would actually argue that concept model archetypes (CMA) are the most essential component of any implementation of concepts -- N2914 or N3351 or else -- in that they are the essential glue to all components:
1. They link the requirements specified in concept definitions with their uses in the definitions of generic components. 2. They tell constraints satisfaction which concept model to look for or generate. Note that: 1. concept model checking reuses constraints satisfaction, and 2. entity reference rebuilding, at instantiation time, is not always necessary---since the need varies based on the design and implementation model. 3. When entity reference rebuilding is supported -- as in ConceptClang's current implementation of N2914 and some flavors of the N3351 implementation, then concrete concept models become particularly essential as well.
In some sense -- and I'm still working on this idea, an implementation of CMAs can indicate the extend to which explicit concept models are needed to bind to customized implementations.
That being said, independently of the concepts design, any parsing and checking of concept definitions should make the implementation of CMAs as easy as possible.
There are other issues that I am currently finding with the semantics of checking entity references in restricted scope, in N2914, but that is something that I should perhaps leave for another discussion. In fact, I would like to run this by people who would be interest at the next committee meeting (next week). The bottom line is that, if I am right, then implementing the checking properly is a complex task -- either due to the implementation structure of Clang or just the nature of C++ grammar. (I'm not sure which one yet.)
That complexity is, unfortunately, one of the main reasons for the hold up on deploying an updated version of ConceptClang.
Just to clarify my point above, I find the idea of automatically generating archetype classes intriguing in the sense that they offer an alternative implementation for CMAs, in contrast to what ConceptClang is currently doing. However, I still wonder if the class template / class template specialization approach to representing concept definitions / concept maps is as powerful as the approach of treating concepts as first class entities of the language. On the other hand, the class template approach removes the need for to rebuild entity references at instantiation time. An alternative that I see that still uses archetypes is for archetype classes to be generated as in the Caramel system. I particularly find this useful in checking constrained template definitions because they allow to do that non-intrusively (or at least less intrusively than the current implementation). That is, instead of checking every dependent entity reference in the body of a template (and all the complexity that comes with it as I'm finding), appropriate archetype classes can simply be instantiated and used on the template upon parsing the template. However, I am not exactly sure how this approach couples up with the checking of the remaining components (concept defns, models, template uses, etc...). I suspect that either it will only be useful if concept maps are not supported; and constraints are only intended to serve as predicates and not provide a scope for name resolution (hence, no need to rebuild entity references). Otherwise, it will be unnecessary with any effort to complement its use. I hope this makes sense somehow...
Thanks, -- Larisse.
- Doug
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost