220 40791 <9f8f8811-f1cb-4f4b-b4fb-15dfa8568881@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why don't concepts look like and get called like functions? Date: Sat, 27 Oct 2018 13:27:57 -0700 (PDT) Lines: 380 Approved: news@gmane.org Message-ID: <9f8f8811-f1cb-4f4b-b4fb-15dfa8568881@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1293_1543572160.1540672078085" X-Trace: blaine.gmane.org 1540671960 17934 195.159.176.226 (27 Oct 2018 20:26:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2018 20:26:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIM7FGT3YCRUBCYLNUXK@isocpp.org Sat Oct 27 22:25:56 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f200.google.com ([209.85.219.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGV9a-0004UV-UB for gclcip-std-proposals@m.gmane.org; Sat, 27 Oct 2018 22:25:51 +0200 Original-Received: by mail-yb1-f200.google.com with SMTP id f8-v6sf3305716ybn.22 for ; Sat, 27 Oct 2018 13:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=AwrXTcxCWaxCX5WhwDwcH5rPuUnE5XfT/eJcacZhOt4=; b=woPKA6Q7xS2IFWokb4e78vSETqIdsD5KyX/4W8KfmOLfRBLhLCGbuef7xoe/uCujQS 9lFeQpt+TnCmV8mBa9H+dgmT6skADwhBl1maPS4abPOgVUUFcfxJ2nmb/nEROLv3shiI i/eOpSNsOteFh8t1YLbD+WFcBwlF9w+/SfHMeWbcY+EpksSysnvi6qjSo8GcX1wqjdf+ kxHg/QuU96gAatPE40pdmAK8wcHp9KSoPN60xc/6p4AdIDJiX+V7emZQVOmtH1I2CDvk pHHSqSDb+2MYES/TD0EVTwExJr8uaVZw4jAFHCxw+hhTMr+cXFpJ8VnP+IdiPqCMZRpX QgYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=AwrXTcxCWaxCX5WhwDwcH5rPuUnE5XfT/eJcacZhOt4=; b=OXHXKSUrOPWC46f6qZ+hplTvOiRHtYMBqpf3tMjdzxt/R68WyeTQu5ei35lYr5u7Dv YxcnwKSRGB6VuBaLTHwEbWUjdnUhT7nYtNCks4fCaljBd9DidqFMiuQ4nMiBW8PEbrer +IqQiAeuwfWiHep8/7TlFTmVnH1bvObrBZNPAsBoz/kD2drRnkp/o2imIUO4dLYFzf43 FJ2mhM/6Di0CQR9nE2tVEEjjf+qE5TxLH8bGOUi8mOUw443fVkDwdZ2RJ8oNea4AG6he zxgN50vqzzPdIIpatNG1xeK2uZjQGCH0al5VMjnwFmfKcXasGdi2tmgZb7yUeciqLITw lswA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=AwrXTcxCWaxCX5WhwDwcH5rPuUnE5XfT/eJcacZhOt4=; b=eKY4QZqlbygLhamFsJp6qh7LCggxIZzIDJn2KSgs8FB4n+oarcMMcYkdWwiZd6lIer BY34uwnPepqJBhP3RuVHmLJ6vZ72VHO94Xj+VinFutJYHdoC040GXwzQSJ8QD0dIjdeT +bNJUwQG7fOlzLUZ208kzPaS9ufKQV3aQHfdaAWeoaPwhl2HCEb7ktM07dd9BSWr4ecl YvvjXRpDSl2Es5QfYYxZhAuLqQZppABvy7iMDm/WchwNDke/9GxpqUWlgyXRCVD8LRW1 Me4Du00xjRENSm4Jl4mcg8rE8ZsLcjpzOgZe2m/FxoRQ0Ogxr46GVHWp7x5/lz5v61aw pOVg== X-Gm-Message-State: AGRZ1gL7mWx+kDOo7NrVMVxz9lmYX2XDLOM+zHm/5Wuacr6FEaz4Ktb7 pCPXTqzdEKNxRnQAYkhtpUu/rg== X-Google-Smtp-Source: AJdET5fA7j579fl2YVDCtxnFrbCeImMmRCaT+eL1oGp2IwAEQMDPOg17gyI2yU9nJGFSX8It6LXmvA== X-Received: by 2002:a25:8b8b:: with SMTP id j11-v6mr4955244ybl.40.1540672080812; Sat, 27 Oct 2018 13:28:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3984:: with SMTP id g126-v6ls2899099ywa.4.gmail; Sat, 27 Oct 2018 13:27:59 -0700 (PDT) X-Received: by 2002:a0d:fc45:: with SMTP id m66-v6mr93118ywf.0.1540672078985; Sat, 27 Oct 2018 13:27:58 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40791 Archived-At: ------=_Part_1293_1543572160.1540672078085 Content-Type: multipart/alternative; boundary="----=_Part_1294_805556285.1540672078086" ------=_Part_1294_805556285.1540672078086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com wrote= : > > A few thoughts on Concepts: > > As Concepts have evolved, I have found it difficult to get a handle on=20 > what Concepts actually are. > i.e.: Are Concepts functions, types, or something else? > Something else. =20 > Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"= =20 > answers that question=20 > clearly. > > In his talk, Bjarne says: > * Concepts are NOT types of types. They are NOT type classes. > Well, they sort-of are. To a first approximation, they're predicates (type= =20 -> bool), which can be understood as partitions of the set of all types. For any type T, either T is-a Range or T is-not-a Range. So the set of=20 Ranges is a subset of the set of all possible types. BUT! Look closer and there are at least three caveats. (1) Concepts have deep structure known as "normal form"; see below. (2) Concepts don't have to map (type -> bool); you can have multi-parameter= =20 concepts such as ConvertibleTo, which are not as easily to gloss as=20 predicates over single types. (But darned if the Concepts TS doesn't try!= =20 For any type T, either T is-a ConvertibleTo or T is-not-a=20 ConvertibleTo.) (3) Concepts don't have to accept types at all. For example, you can make a= =20 concept that maps (int -> bool). template concept EvenValue =3D ((V % 2) =3D=3D 0); I don't think this kind of concept is useful in real code (I'd prefer this= =20 kind of concept be kicked out of the Working Draft before C++2a is=20 shipped). But you definitely can't by any mental gymnastics claim that=20 concept `EvenValue` is a "type function" or a "type of types" or anything= =20 remotely like that. At around 1:06:30 in his talk Bjarne says: > * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS". > I believe that was an ad-lib not to be taken 100% literally. To a first=20 approximation, a concept like Mergeable is a function mapping an ordered=20 tuple of types to a bool. But that doesn't mean that *all concepts ever*=20 must be thought of as functions. That way lies functional programming and madness. ;) [...] > The Concepts defined in Bjarne's talk look more like variable definitions= =20 > *defined* in what feels (to me) like an odd mix of logic and type like=20 > syntax: > > template using Value_type =3D X::value_type; > template using Iterator_of =3D X::iterator; > > template > concept Mergable =3D > ForwardIterator > && ForwardIterator > && OutputIterator > && Assignable,Value_type> > && Assignable,Value_type> > && Comparable,Value_type>; > > The above looks like a variable definition. If it is not, then is it righ= t=20 > that it looks like one? > It's a definition, with conditional logic et al. i.e it uses &&. etc. lik= e=20 > an inline function. > So why are we defining it NOT using function like snytax? > Why is this a good thing? > Because of the first caveat I listed above: Concepts are not *just*=20 predicates. They are logical predicates with deep structure, described by= =20 their *normal form*. For example, there is no special relationship between= =20 the variable templates template inline constexpr bool is_scalar_v =3D=20 std::is_scalar::value; template inline constexpr bool is_integral_v =3D is_scalar_v=20 && std::is_integral::value; but there is a very special relationship between the concept( template)s template concept is_scalar_c =3D std::is_scalar::value; template concept is_integral_c =3D is_scalar_c &&=20 std::is_integral::value; The special relationship is called *subsumption*, and we say that=20 is_integral_c *subsumes* is_scalar_c. If it weren't for subsumption, there would be no fundamental difference=20 between a concept and a variable template of type `bool`. The compiler determines the subsumption relationships between concepts by= =20 cracking open their definitions and peering inside. The definitions are=20 cracked open *only* along the boundaries of the logical `&&` and `||`=20 operators. So it is critically important that the definition of a concept= =20 be a single logical expression. If a concept were allowed to be expressed= =20 as a function body, the compiler wouldn't be able to crack it open, lift it= =20 into *normal form*, and figure out the *subsumption* relationships between= =20 this concept and all the other concepts in your program. Figuring out these relationships is important to the compiler because these= =20 relationships affect overload resolution. Please see my CppCon 2018 talk "Concepts as she is spoke"=20 for a truly painful amount = of=20 information on how Concepts are different from plain old variable templates= .. [...] > 1. If concepts ARE functions, why aren't we defining and using them with= =20 > function like syntax? And using () not <>. > I hope my answers above have pointed the way on this one. =20 > 2. It seems J. Monnon's proposal is making the same point as I am, only= =20 > much better? Can we please address all that he proposes? > I think P0844 "Type functions and beyond"=20 is= =20 thought-provoking. It's very large, though, which I believe is why it's=20 targeted at SG7 Compile-Time Programming (formerly SG7 Reflection). P0844 major section 3, "Concepts introducing types," seems to ignore the=20 existence of non-type concepts in the Working Draft. Perhaps there should= =20 be a concerted effort to *kick non-type concepts out of the Working Draft*= =20 in order to gain some freedom of motion for these recurring theories of=20 "concepts =3D=3D types of types." I do not believe that P0844 is making the same points (or, asking for=20 clarification on the same points) as you are. I have only skimmed P0844,=20 but it does not seem to be engaging with Concepts-as-they-are at all; it=20 seems to be trying to reuse Concepty words to refer to elements of the=20 author's more na=C3=AFve "types of types" theory. (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far* t= oo=20 much of an experts-only feature, and we could use a lot more naivet=C3=A9 i= n=20 this area.) 3. I feel a more formal response to J. Monnon's paper from the main=20 > proponents of Concepts as currently defined should be made before concept= s=20 > get wired in any further in it's current direction? > > I know many people would like Concepts be the marquee feature of C++20,= =20 > but to me Concepts still seem quite away from where I'd like them to be. > Even Bjarne can only 'begrudgingly live' with the current syntax. > All this flux and begrudging really doesn't suggest to me that Concepts= =20 > are ready to go for C++20. > FWIW, I agree with your conclusion. The question is, do C++2a Concepts need wholesale kicking-out, as happened= =20 in C++11? or can they be rescued by judicious cuts? The other question is, can anyone stop Concepts at this point or are the=20 wise people getting out of the way of the train? (Cynic says: observe the= =20 recent formation of EWGI and LEWGI for those people tired of engaging with= =20 C++2a issues and eager to move on to C++2b.) =E2=80=93Arthur --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/9f8f8811-f1cb-4f4b-b4fb-15dfa8568881%40isocpp.or= g. ------=_Part_1294_805556285.1540672078086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis..= ..@gmail.com wrote:
A few thoughts on Concepts:

As Concepts = have evolved, I have found it difficult to get a handle on what Concepts ac= tually are.
i.e.: Are Concepts functions, types, or something else?

Something else.
=C2=A0

In his talk, Bjarne says:
* Concepts= are NOT types of types. They are NOT type classes.


Well, they sort-of are. To a first approximation, th= ey're predicates (type -> bool), which can be understood as partitio= ns of the set of all types.
For any type T, either T is-a Range o= r T is-not-a Range. So the set of Ranges is a subset of the set of all poss= ible types.
BUT! Look closer and there are at least three caveats= ..
(1) Concepts have deep structure known as "normal form&quo= t;; see below.
(2) Concepts don't have to map (type -> boo= l); you can have multi-parameter concepts such as ConvertibleTo<T,U>,= which are not as easily to gloss as predicates over single types. (But dar= ned if the Concepts TS doesn't try! For any type T, either T is-a Conve= rtibleTo<U> or T is-not-a ConvertibleTo<U>.)
(3) Conc= epts don't have to accept types at all. For example, you can make a con= cept that maps (int -> bool).

=C2=A0 =C2=A0 tem= plate<int V>
=C2=A0 =C2=A0 concept EvenValue =3D ((V % 2) = =3D=3D 0);

I don't think this kind of concept = is useful in real code (I'd prefer this kind of concept be kicked out o= f the Working Draft before C++2a is shipped). But you definitely can't = by any mental gymnastics claim that concept `EvenValue`=C2=A0is a "typ= e function" or a "type of types" or anything remotely like t= hat.


At around 1:06:30 in his talk Bjarne says:* "it's just like defining functions, you *ARE* DEFINING FUNCTION= S".


I believe that was an ad= -lib not to be taken 100% literally. To a first approximation, a concept li= ke Mergeable is a function mapping an ordered tuple of types to a bool. But= that doesn't mean that all concepts ever must be thought of as = functions.
That way lies functional programming and madness. ;)

[...]
The Concepts defined in Bjarne's talk look = more like variable definitions *defined* in what feels (to me) like an odd = mix of logic and type like syntax:

template<typename X> u= sing Value_type =3D X::value_type;
template<typename X> using Iter= ator_of =3D X::iterator;

template<typename For, typename For2, typ= ename Out>
concept Mergable =3D
=C2=A0=C2=A0=C2=A0 ForwardIterator= <For>
=C2=A0=C2=A0=C2=A0 && ForwardIterator<For2>=C2=A0=C2=A0=C2=A0 && OutputIterator<Out>
=C2=A0=C2=A0=C2= =A0 && Assignable<Value_type<For>,Value_type<Out&g= t;>
=C2=A0=C2=A0=C2=A0 && Assignable<Value_type<For2>= ;,Value_type<Out>>
=C2=A0=C2=A0=C2=A0 && Comparabl= e<Value_type<For>,Value_type<For2>>;


The above looks like a variable definition. If it is not, then is i= t right that it looks like one?
It's a definition, with conditional = logic et al. i.e it uses &&. etc. like an inline function.
So why are we defining it NOT using function like snytax?
Why is t= his a good thing?

Because of th= e first caveat I listed above: Concepts are not just predicates. The= y are logical predicates with deep structure, described by their normal = form. For example, there is no special relationship between the variabl= e templates

=C2=A0 =C2=A0 template<class T> = inline constexpr bool is_scalar_v =3D std::is_scalar<T>::value;
=
=C2=A0 =C2=A0 template<class T> inline constexpr bool is_integra= l_v =3D is_scalar_v<T> && std::is_integral<T>::value;

but there is a very special relationship between th= e concept( template)s

=C2=A0 =C2=A0 template&= lt;class T> concept is_scalar_c =3D std::is_scalar<T>::value;
=C2=A0 =C2=A0 template<class T> concept is_integral_c =3D is_sc= alar_c<T> && std::is_integral<T>::value;

The special relationship is called subsumption, and= we say that is_integral_c<X> subsumes is_scalar_c<X>.
If it weren't for subsumption, there would be no fundamental d= ifference between a concept and a variable template of type `bool`.

The compiler determines the subsumption relationships bet= ween concepts by cracking open their definitions and peering inside. The de= finitions are cracked open only along the boundaries of the logical = `&&` and `||` operators. So it is critically important that the def= inition of a concept be a single logical expression. If a concept were allo= wed to be expressed as a function body, the compiler wouldn't be able t= o crack it open, lift it into normal form, and figure out the sub= sumption relationships between this concept and all the other concepts = in your program.

Figuring out these relationships = is important to the compiler because these relationships affect overload re= solution.

Please see my CppCon 2018 talk "Concepts as she is= spoke" for a truly painful amount of information on how Concepts = are different from plain old variable templates.

[= ....]
1. If concepts ARE functions, why aren't we defining and using them w= ith function like syntax? And using () not <>.

I hope my answers above have pointed the way on t= his one.
=C2=A0
2. It seems J. Monnon's proposal is making the s= ame point as I am, only much better? Can we please address all that he prop= oses?

I think P0844 &= quot;Type functions and beyond" is thought-provoking. It's ver= y large, though, which I believe is why it's targeted at SG7 Compile-Ti= me Programming (formerly SG7 Reflection).
P0844 major section 3, = "Concepts introducing types," seems to ignore the existence of no= n-type concepts in the Working Draft. Perhaps there should be a concerted e= ffort to kick non-type concepts out of the Working Draft in order to= gain some freedom of motion for these recurring theories of "concepts= =3D=3D types of types."
I do not believe that P0844 is maki= ng the same points (or, asking for clarification on the same points) as you= are. I have only skimmed P0844, but it does not seem to be engaging with C= oncepts-as-they-are at all; it seems to be trying to reuse Concepty words t= o refer to elements of the author's more na=C3=AFve "types of type= s" theory.
(More na=C3=AFve is not necessarily bad! =C2=A0I = think C++2a Concepts is far too much of an experts-only feature, and= we could use a lot more naivet=C3=A9 in this area.)

3. I feel = a more formal response to J. Monnon's paper from the main proponents of= Concepts as currently defined should be made before concepts get wired in = any further in it's current direction?

I know = many people would like Concepts be the marquee feature of C++20, but to me = Concepts=C2=A0still seem quite away from where I'd like them to be.
= Even Bjarne can only 'begrudgingly live' with the current syntax.All this flux and begrudging really doesn't suggest to me that Concep= ts are ready to go for C++20.

FWIW, I agree with your conclusion.
The question is, do C++2a = Concepts need wholesale kicking-out, as happened in C++11? or can they be r= escued by judicious cuts?
The other question is, can anyone stop = Concepts at this point or are the wise people getting out of the way of the= train? (Cynic says: observe the recent formation of EWGI and LEWGI for tho= se people tired of engaging with C++2a issues and eager to move on to C++2b= ..)

=E2=80=93Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9f8f8811-f1cb-4f4b-b4fb-15dfa8568881= %40isocpp.org.
------=_Part_1294_805556285.1540672078086-- ------=_Part_1293_1543572160.1540672078085-- .