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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-10 17:06:23

Le 10/10/12 21:17, Matt Calabrese a écrit :
> On Wed, Oct 10, 2012 at 1:08 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:
>
>> Can we write down pros and cons for concepts implemented via
>> pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns
>> (N3351 and Boost.Contract)?
>>
>> Who wants to start? Matt, Dave, Andrzej, ... I can compile a qbk table
>> with what we discuss.
>
> We should possibly take this discussion to
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-discussion
>
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals
> as
> Dave suggested in the other thread.
>
> First, some initial properties -- some of these aren't really clear pros or
> cons, just differences as they come to mind, unorganized. I am not on the
> standards committee and am definitely not an expert concerning the
> usage-patterns approach, so other people would probably be able to produce
> much better lists than these (it'd be nice to have I.E. Doug Gregor and
> Andrew poke their head in here, but I know they're busy). I'm also biased
> toward pseudo-signatures, as is Dave at least (I don't know about Andrzej),
> so we really need someone more committed to usage-patterns to be able to
> highlight the benefits and drawbacks.
>
> Usage-patterns:
> - Usage-patterns show valid expressions and properties of expressions that
> deal with the concept's arguments (mostly subjective if this is pro or con)
On simple cases this is not an advantage but there are cases that 
writing the pseudo-signatures is quite complex(or even impossible) if we 
don't want to say more than what the usage pattern says.

for example

f(a)

requires that there is an unique overload of f that can be found for f(a)

With pseudo signatures we could state that there is a function f with a 
parameter T and that a is implicitly convertible to T.

void f(T) requires (Convertible<decltype(a), T>

Note that a model that defines

int f(A)

satisfies the usage patter f(a) but not the pseudo signature. I don't 
see how to introduce the type R if it is not part of the concept parameters.
> - Concept definitions are very different syntactically from other
> definitions in C++ (possible con)
> - An Individual required usage pattern may be more complicated than a
> single function call (possible pro)
> - A usage patterns cannot have a default implementation (con)
> - The use of givens more closely matches the way concepts were specified in
> previous standards (pro, though this only realistically affects people who
> deal with the standard)
> - Exactly what types of argument can be passed to associated functions may
> not be apparent to the user since since you have to deduce a function
> declaration based on the types of the givens (and consider convertibility,
> etc). (con)

> - Generation of sensible archetypes is not immediately apparent (at least
> to me), particularly when considering associated function parameter types
> since again, those types would have to be deduced from arguments being
> passed, not a function signature. (con)
Well, this is always a problem for the concept developer as she needs to 
do this work once.
> - N3351 doesn't mention archetypes at all (*cough* they're important
> *cough*) (con)
>
> Pseudo-signatures
> - A concept definition looks and "works" very similarly to the definition
> of a type that models the concept being defined (IMO big pro)
> - Writing and reading a generic algorithm that deals with a concept is very
> similar to writing and reading an algorithm that deals with a type
> definition since you are essentially writing to an archetype (pro)
> - Pseudo-signatures can have defaults (pro)
I find this a big advantage.
> - noexcept being applied to an associated function requirement is very
> simple to do with pseudo-signatures in the same way that you'd augment a
> regular function declaration (though N2914 didn't yet have noexcept) (pro)
> - Concept definitions do not look like the way concepts were specified in
> previous standards (con)
> - "Proper" archetype generation from pseudo-signatures is much more clear
> than with usage-patterns, though usage patterns here may not be as bad as I
> am imagining (pro)
> - Archetypes are fundamental to N2914 (pro)
> - This approach made it very far through the standardization process and
> its language/library components were chiseled into what ended up in N2914
>
> Again, I am biased toward the pseudo-signature approach, so I may not be
> giving usage-patterns the representation that they deserve. Also, while I
> have a lot of experience emulating N2914 in C++11 and know it very well, I
> would not consider myself an expert.
>
On the context of Boost.Contract, I would add a pros for the Pseudo 
signatures,  that is, we can associate pre-conditions to the Pseudo 
signatures, which seems quite complex for usage patters . We could add 
even concept invariants and know exactly when these should be checked by 
the model.

Has someone even think for one moment that we could use both mechanism, 
depending on the specific context.

Just my 2cts.
Vicente