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 16:35:48

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