Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request

5 Aug 2014

      On Mon, 04 Aug 2014 08:39:36 -0700, Roland Bock  wrote:
...
On 2014-08-04 13:32, Mostafa wrote:
...
On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey  wrote:
...
Eric Niebler-4 wrote
...
On 07/29/2014 05:14 PM, Niall Douglas wrote:
...
I'm all for Concepts as in compiler enforced ones, and I'll add them
to AFIO when and only when C++ gets them. But for documentation they
don't help.
Wow, I couldn't disagree more. I can't imagine how the standard
algorithms would be specified without the use of concepts like
"RandomAccessIterator", for instance. Clustering requirements into
meaningful abstractions and assigning them names makes it possible to
document library interfaces without an explosion of verbosity and
repetition.
+10
Usage of concepts is greatly:
a) misunderstood
b) misunderestimated as to their value in design AND documentation
d) The word "concepts" is a big contributor to the problem - substitute
"type requirements" or "type constraints" for concepts.
-1 to the above term substitutions for concepts. Type requirements/type
constrains are not concepts. The reason concepts are misunderstood is
because they have not been well defined. FWIW, here's my take on how  
they
should be defined:
Concepts are sets of types whose membership are compile-time
determinable.
I think you are mistaken. A concept is a set of requirements, not a set
of types that fullfill these requirements.
I understand that some may have a problem with such a definition because  
it does not have an immediate programmatic counterpart. That is we can  
only implement concept checks, hence Boost.ConceptChecks, and not concepts  
themselves in C++. But I view concepts not as a programmatic tool but as a  
communication tool for conveying programmer intent.

The main reason I hold this view is because it's easier to think in terms  
of sets of types than in terms of sets of type requirements. For example,

ShapeConcept := { T | T has the method "void display() const" defined }
TriangleConcept :=
   { T | T models Shape and T has the following methods defined:
         "Edge edgeOne()", "Edge edgeTwo()", "Edge edgeThree()" }

// T models ShapeConcept
template <typename T>
void Display(T & t);

It's obvious that if U models a TriangleConcept then Display(u) for an  
object u of type U is well-formed. (That's because TriangleConcept is a  
subset of ShapeConcept and U is a member of the latter.) Note that this is  
similar to the relationship between types and objects. Conceptually types  
are sets of objects and a subtype contains a subset of the objects of its  
supertype.

Now, let's try reworking the above example in terms of sets of type  
requirements instead. The TriangleConcept then is a refinement of  
ShapeConcept if the TriangleConcept is a superset of the ShapeConcept. But  
that's counter-intuitive because the number of types that satisfy the  
TriangleConcept is less than the number of types that satisfy ShapeConcept.

Additionally, if concepts were sets of type requirements than the phrase  
"T is DefaultConstructible" reads awkwardly, it almost sounds as if T were  
a type requirement itself, when we actually mean to say that T satisfies  
the requirements of default constructibility. And the language "x  
satisfies abc" usually connotates set membership.
...
This also reflects the normal meaning of the word concept, see for  
instance
http://www.oxforddictionaries.com/definition/english/concept
??? From the above link:
"1.4 Philosophy An idea or mental image which corresponds to some distinct  
entity or class of entities, or to its essential features, or determines  
the application of a term (especially a predicate), and thus plays a part  
in the use of reason or language."

Mostafa