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 11:33:22

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

Incidentally, it would be interesting to see if we one can implement a
truly complete archetype generator.
The following paper, on the Caramel system, hints at a few issues with this
alternative:
http://www.osl.iu.edu/publications/prints/2001/TMPW01:_Willcock.pdf

I'd be interested in learning about experiences using this system (or
extensions of it) on various generic libraries.
Any idea?

Thanks,
-- Larisse.

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