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 09:53:01

On Fri, Oct 12, 2012 at 3:05 PM, Doug Gregor <doug.gregor_at_[hidden]> wrote:

> On Fri, Oct 12, 2012 at 6:25 AM, Andrew Sutton <asutton.list_at_[hidden]>
> 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.

Thanks,
-- Larisse.

>
>   - Doug
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>