Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-13 17:10:45

on Sat Oct 13 2012, Larisse Voufo <lvoufo-AT-indiana.edu> wrote:

> On Sat, Oct 13, 2012 at 9:53 AM, Larisse Voufo <lvoufo_at_[hidden]> wrote:
>
>>
>>
>> On Fri, Oct 12, 2012 at 3:05 PM, Doug Gregor <doug.gregor_at_[hidden]>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.  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."  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...

>> 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"

>> 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?"
"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.

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.

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.

> 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.
> 
> 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.

> 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.

> 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.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost