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

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-05 03:07:42

On 2014-08-05 02:08, Mostafa wrote:
> On Mon, 04 Aug 2014 08:39:36 -0700, Roland Bock <rbock_at_[hidden]> wrote:
>
>> On 2014-08-04 13:32, Mostafa wrote:
>>> On Thu, 31 Jul 2014 10:54:59 -0700, Robert Ramey <ramey_at_[hidden]>
>>> 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.
That's not an argument IMHO. Even if a concept C is a set of
requirements, you can think of the set of types that meet these
requirements, lets call them T(C).

Then for two concepts A and B, we call A a refinement of B if T(A) is a
subset of T(B).

So you can still express everything you want to express and the concept
is what we write in code: A set of requirements.

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

See above.

And sure, if concept A is a superset of concept B, then T(A) is a subset
of T(B). There is nothing counter-intuitive about that afaict.

>
> 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.
Sure, that type is a member of T(DefaultConstructible).

I don't get your argument at all. If you say "this car is green", you
say both "this car is a member of the set of green things" and "this car
meets the requirements of being green". It does neither imply that
"green is the set of green things" (endless recursion) nor does it say
that "green is a set of being-green-requirements" (also endless
recursion). Still, everyone knows what is meant without feeling awkward
about it.

So why not use the term concept in a way that matches what we actually
do in code?

>> 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."
In short (and probably not precise enough since I am not a philosopher),
a concept is not a thing (aka type in template programming) or set of
things, it is an idea about it or its essential features, for instance a
predicate.

Regards,

Roland