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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Larisse Voufo (lvoufo_at_[hidden])
Date: 2012-10-13 18:07:54

Thanks for the feedback. Hopefully I'm addressing your comments well below.

On Sat, Oct 13, 2012 at 5:10 PM, Dave Abrahams <dave_at_[hidden]> 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_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.

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", 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 and
N2914, that is, as embedded with the checking of template definitions.

In other words, there seems to be an implicit assumption that declarations
in concept model archetypes
corresponding to the template's constraints ought to be injected into the
associated template parameter scope.
Therefore, the notion of concept model archetype is implicit and doesn't
have an explicit representation in the compiler.

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

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

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.

> >> 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".
> "bind to?"  -- e.g. a function call binds arguments to a function
> declaration.
> "customized implementations?"  -- i.e. implementations in concrete concept
> models.
>
> >> 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.

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

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

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

>
> > 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).
When are the calls in the template definitions bound to the concept model
archetypes?

>
> --
> Dave Abrahams
> BoostPro Computing                  Software Development        Training
> http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>