on Sat Oct 13 2012, Larisse Voufo <lvoufo-AT-indiana.edu> wrote:
Thanks for the feedback. Hopefully I'm addressing your comments well below.
On Sat, Oct 13, 2012 at 5:10 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Sat Oct 13 2012, Larisse Voufo <lvoufo-AT-indiana.edu> wrote:
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:
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
^^^^^^^^
This word seems to imply that you think you are contradicting Doug, but to me it sounds like what you say here reinforces his statement.
I don't think I'm contradicting Doug in terms of archetypes and template definitions being important. I am just not sure that his proposed implementation is sufficient, hence the "something".
The only way I can make sense of this is to assume you mean something different by "concept model archetypes" than Doug and I mean when we say "archetypes."
I think that when you guys say "archetypes", you mean both "type archetypes" and "concept model archetypes",
I don't know what either of those things are, so saying that doesn't mean much to me.
and I find the term sometimes ambiguous to me. I also think you think of them in terms of how they are implemented in ConceptGCC
No; I've never looked at the implementation. And, by the way, baseless assumptions that perspective has been distorted by too much familiarity with a particular implementation are a sore point for some of us. I guess you picked them up from part of the culture around this project, so I don't blame you, but I suggest that they are unhelpful when trying to understand my point of view.
and N2914, that is, as embedded with the checking of template definitions.
I don't know what you mean by that. When I say "archetypes" I mean what's described in http://www.boost.org/doc/libs/1_51_0/libs/concept_check/concept_covering.htm. In the context of a language feature, I expect them to be generated automatically by the compiler based on concept declarations and constraints. I do expect them to be used in checking template definitions.
In other words, there seems to be an implicit assumption that declarations in concept model archetypes ^^^^^^^^^^^^^^^^^^^^^^^^ Here's that undefined term again.
corresponding to the template's constraints ought to be injected into the associated template parameter scope.
Until you define your terms, I'm not going to be able to respond usefully to the above. An example would be very helpful here also.
Therefore, the notion of concept model archetype is implicit and doesn't have an explicit representation in the compiler.
Just based on the grammar of what you said, without fully grasping the meaning, I don't see how that sentence could be a logical conclusion of what comes before.
Further, constraints satisfaction and the ^^^^^^^^^^^^^^^^^^^^^^^^ binding of entity references, at instantiation time, with respect to ^^^^^^^ ^^^^^^^^^^^^^^^^^ model implementations comes for free with the treatment of concept models as class template specializations.
In the WGP ConceptClang paper,
By which you mean http://www.generic-programming.org/software/ConceptClang/papers/wgp06v-voufo... ? I note that most of these terms you're throwing around don't appear in that paper.
we made the distinction that:
1. We didn't need type archetypes in ConceptClang since Clang ^^^^^^^^^^^^^^^ already does a good enough job treating template type parameters as types.
2. We gave concept model archetypes explicit representations as simply ^^^^^^^^^^^^^^^^^^^^^^^^ concept models satisfied by substituting declarations over from their mapped concepts. This way it is clear to see the two main roles that constraints are supposed to serve: Acting as predicates and providing scope for name resolution. 3. In the body of template definitions, names no longer bind to declarations inside class template specializations. Rather, to declarations in the concept model archetypes, which are basically placeholders for when ^^^^^^^^^^^^^^^^^^^^^^^^ we have concrete maps at the point of template use.
4. At the point of template use, constraints satisfaction explicitly performs concept model lookup and needs to rebuild ^^^^^^^^^^^^^^^^^^^^ entity references that were bound to declarations in archetypes so ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ that they now bind to declarations in the concrete concept models.
I think the paper goes further on key distinctions, but the basic idea is that we have decoupled the notion of concept model archetypes with ^^^^^^^^^^^^^^^^^^^^^^^^ their implementation, which provides more genericity and allows us to really understand how the design decisions we make affect the different components of concepts: concept definitions, concept models (templates, archetypes, or concrete), constrained template definitions -- w/ constraints specification, and constrained templates uses -- with constraints satisfaction, followed by a rebuilding of the references at instantiation time.
Given this distinction, I hope it is now clear how the implementation that Doug suggests is simply a special case of a larger infrastructure.
Unfortunately, nothing is now clear, because you haven't clearified your terms and distinctions.
Whether it is the right approach or not, I think some parameters still need to be investigated further. If I am not mistaking, I read a paper at some point that addressed how c++ concepts where not completely expressible in terms class templates and their specializations. But I have to double-check on that.
They are indeed not. Early on, they were nearly so IIUC, but rvalue-erasing and the creation of unnecessary copies put an end to that. Of course there are always also new lookup rules involved in a concepts implementation, but I don't think you are referring to that dimension of things.
Unfortunately, although you're wielding it as though it were a term of art, you haven't defined it, so it's hard to be sure...
I'm sorry for not clarifying myself well earlier. It is definitely in the ConceptClang paper though.
Umm, which one? There are three listed at http://www.generic-programming.org/software/ConceptClang/. As I mentioned, the first one doesn't define many of the terms you use.
Thanks for pointing out my differing terminology. I am updating it as I get more accustomed with C++ terminology.
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.
Other terms of art used without definition here: "constraints satisfaction" (one can guess, but you seem to be referring to something very specific, so one could be wrong) and "entity reference rebuilding"
I don't believe "constraints satisfaction" is a term of my making. I borrowed it from previous litterature on concepts. I did make up "rebuilding", but not "entity reference" (I don't think). Either way, I am not sure what the right C++-compatible terminology would be. Any idea? I tried to explain the concept above as the rebinding of names from concept model archetypes to concrete concept models. Please let me know if I can be any clearer.
You can be clearer. I don't yet know what you mean by "concept model archetypes," so it's hard to make head or tail of any of this. From the context, I am beginning to suspect that my "archetype" == your "concept model archetype," but I am not yet sure.
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.
"explicit concept models?" -- i.e. explicit modeling mechanism for concepts, as in "explicit concepts".
This is unclear. I don't think this term can mean a mechanism at all. By "explicit concept model" I think you mean "one or more types that have been explicitly declared by the user to model a concept." However, you're using it in the sentence as though you mean the declaration itself.
"bind to?" -- e.g. a function call binds arguments to a function declaration.
"bind to" will probably make plenty of sense once you clarify the other terms.
"customized implementations?" -- i.e. implementations in concrete concept models.
Sounds like you just mean the extent to which explicit model declarations are needed and you don't need "to bind to customized implementations" which probably really means "to bind concepts to concrete models" because, after all, an explicit model declaration binds a given concrete concept model to the concept; I mean, that's *all* it does!
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.
I don't know what ConceptClang is currently doing, but if (as you seem to imply) you're not doing checking by generating concrete archetypes and instantiating constrained templates with them, then
a. You are setting yourself up for a great deal more work than necessary, because you have to implement a complex algorithm that closely parallels what C++ already does.
Actually, I'd like to argue that the algorithm actually helps find some incompleteness with previous work. That's the point of ConceptClang to begin with.
Seriously, to find problems with previous work?
b. The semantics of your checking are much more likely to "not make sense" to C++ users today, because the rules will be subtly different.
The semantics are just the same, but more implemented more abstractly, i.e. I think of components of concepts separately from previously proposed implementations.
As noted above, please drop that line of assumption about others' thinking.
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.
They're not mutually exclusive. The "first class entities in the language" might intentionally be defined (as they were in N2914) to have the same semantics as existing language features, and thus be implementable in terms of the same code.
That's what I'm not too sure about, just yet... And like I said earlier, I could be missing something.
Could be.
On the other hand, the class template approach removes the need for to rebuild entity references at instantiation time.
There's that term of art again.
Sorry. :)
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.
I'm truly surprised to hear (if I'm understanding correctly) that you didn't go down that road in the first place. I think it was well-understood to be the obvious approach.
This is a different alternative which is not like Doug's suggestion above, but rather like BCCL's archetypes.
I seriously doubt Doug means something different from BCCL's archetypes in any important respect. Of course, I could be wrong, but when Doug and I talk and one of us says "archetype," there's never any confusion about what's meant.
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.
You mostly lost me with the last paragraph.
Let's take the example of constrained function templates. Simply instantiating archetypes, constructing a new call expression with them, and checking that call only checks for concept coverage. (I'm borrowing the terminology from the BCCL paper).
Yes. What else do you want to check?
When are the calls in the template definitions bound to the concept model archetypes?
Example please. I can guess at what you mean about "binding a call to a concept model archetype", but it would be better if you'd spell it out. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost