220 38461 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Concepts fragmentation problem Date: Sun, 3 Jun 2018 11:47:01 -0700 (PDT) Lines: 161 Approved: news@gmane.org Message-ID: References: <48f336e3-146b-4317-8a60-1a3acc16af4b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18562_1769981434.1528051621775" X-Trace: blaine.gmane.org 1528051497 19358 195.159.176.226 (3 Jun 2018 18:44:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2018 18:44:57 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJXP2DMAKGQEWKKGT2Y@isocpp.org Sun Jun 03 20:44:53 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPXzo-0004vM-Ej for gclcip-std-proposals@m.gmane.org; Sun, 03 Jun 2018 20:44:52 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id n201-v6sf10473036ywd.17 for ; Sun, 03 Jun 2018 11:47:03 -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=JrIuvbEXz07ClL2bUkkFVW++y3wSZMVM93G5WdnS+SM=; b=zAAZA6Y6T37Ig0BNBhxRuolQPXJOfVb/mc2i2GeK1z5mlykTSXk9rNJ22Y8vrQ1Vqh AD9S7r7SokwSePeY6lKUIYqWpcpzYa4YcE+F80qN6bdDJ1ZR8DhsW6pRtWZ8JMJJM8Dd J8SIyXlPMi3Eb/zVMGNzOMDXUL9kQ9+XUzPblyEwqCIRz9njcDA+D/glc/teUeVTeEG2 nqwAE1SXuB5YDXqKWXaOgKOUHWHLaHkE+27zvObjrC1KEs0yIosBXRdST4lnaUzj0VC1 bsy5BIyPqrTY+ETcMQgXijFbgZO71h6Rk2KH/4lqqednduCmlJljaEo4PVyMUxzmZdLw tvCg== 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=JrIuvbEXz07ClL2bUkkFVW++y3wSZMVM93G5WdnS+SM=; b=a3A0SsDY6lnvgJrEz32XIQ9jhRv4G1K4wU0g0VPboDzhsagFIGxXm9IPaBjCMEMB3o xmb4TqoWMshwY2p6adehRaWgfHMqpSiuZYEyrxULQmvfblkUJzN4qqVm7FUnL1i/al7u kvV6K3l8s4zn9QFle1UBkYesNgw5mb6iQfJm5GkkxVguLMeYyrG45j7FYzl6aAlQ+sEl CaQmPZv6FEelVoAe+uDVRP9GLYjj1y9DtJ2JWPuAxEgZ/kkh7SSm2wLxtAmGxtb47fBE QkobBBPaND5/XbuD+oDcw+jwRuX3yYJl8GgAnZpn6WiTTemIj2rml8+Hp76NfDsRQvJF pBxw== 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=JrIuvbEXz07ClL2bUkkFVW++y3wSZMVM93G5WdnS+SM=; b=avC8w+7Ifz+KY2dRfMOIq+UQPPuKIh32+Rffd9NqTJrRVZIWSfu6XfVQyERAm3eLQj DtShk0hqKL7hlWdaC28PBppgEG9jxdq/atrqLHdE3GzqnxiDfkW89MMH8ia4ZWHTgLDJ U78oItkHq3oFiMGpAWnpaQMB+Jqd2/eHUTDshAqQCmBJbWa/4o5A5DsanbrU2eLAocio zZ77XOgx66nBzIjLnJ17KboPx4F9AAoEcpUGkL5p5ImVQo9Dq75K9mYOnaRR3nKWn2xn tcLHY2qXgtcH412LznCxsRLPLmwqHVcyDjj6jknoV/OKIom0Xouca9fCzgRwpkJaB+Or Lb8w== X-Gm-Message-State: APt69E0fuFww84CEmUTf6gfOAxe5CaRf0LHnkaOmduHh4SEnY3DiAG0n CqaczSVY+y3GkRT2RrieZ/nNPA== X-Google-Smtp-Source: ADUXVKKxox/95ovPgHMgLFi+yqTV+nQjlV1i+sSANy51khgXxT3XlUxEu9ByZai38HpYId8wlEFJxg== X-Received: by 2002:a81:4305:: with SMTP id q5-v6mr1339289ywa.198.1528051623274; Sun, 03 Jun 2018 11:47:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:c0cf:: with SMTP id c198-v6ls1596558ybf.16.gmail; Sun, 03 Jun 2018 11:47:02 -0700 (PDT) X-Received: by 2002:a5b:a8c:: with SMTP id h12-v6mr820741ybq.10.1528051622341; Sun, 03 Jun 2018 11:47:02 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:38461 Archived-At: ------=_Part_18562_1769981434.1528051621775 Content-Type: multipart/alternative; boundary="----=_Part_18563_1747966124.1528051621776" ------=_Part_18563_1747966124.1528051621776 Content-Type: text/plain; charset="UTF-8" On Sunday, June 3, 2018 at 1:01:32 PM UTC-4, Omer Rosler wrote: > > On Sunday, June 3, 2018 at 4:59:34 AM UTC+3, Nicol Bolas wrote: > > On Saturday, June 2, 2018 at 7:57:30 PM UTC-4, Omer Rosler wrote: > > > > > > > > The problem with second approach the user now has to remember two > versions of the same concepts: one to use and one to implement. > > > > > > How many times have you used an iterator? I bet it's several orders of > magnitude more often than you've written one. > > > > > > Yes, your library has two concepts. But they aren't two versions of the > same concept. There's the Iterator concept, and there's the > ThingThatThisToolTurnsIntoAnIterator concept. Those aren't the same thing; > indeed, more likely than not, they are quite dissimilar. They have > different interfaces and different purposes. > > > > > > Users don't have to remember the ThingThatThisToolTurnsIntoAnIterator > concept, because they simply don't use it very often. When they need to use > it, they'll look up what it does and how it works. What they're going to > remember is Iterator, because that's what they're using most of the time. > > Well the iterator comparison for the ratio of uses/implementations is not > fair as this is not the case for every concept library out there. > There is a second problem with this separation into two concepts: > Consider a customization point in the users' concepts that is given via a > traits class. > If that customization is not given by the ThingThatTurnsIntoMyConcept > (then this concept also has a traits class) then users and implementers use > different customization points which costs the library in a lot more > metaprogramming pain just because it uses concepts. > Let's be more specific about the problem, using iterators as kind of a model for the idea. Iterators have a lot of interfaces. This makes them easy to use, so those interfaces provide value. So that's your "consumption concept", one that's optimized based on the usefulness to the code using such objects. But implementing iterators, particularly from range-like starting points, is painful. It often requires a lot of repetition or writing a lot of boilerplate. You could imagine a far more simplified interface. But you don't want users to *use* that interface, because the interface is less usable than the Iterator interface. This is your "implementation concept". These two concepts have *nothing* to do with one another. They are two different concepts for two different users with two different use cases. The only association between them is that there is some piece of metaprogramming code which takes objects which abide by the implementation concept and generates objects for the consumption concept. But this is merely a *helper tool* for the consumption concept. It is not a fundamental or essential part of that concept. After all, nobody is *forcing* you to use this particular tool. If you want to write your Iterator type without help, you certainly can do so. As long as you conform to the consumption concept, you're fine. Not only that, you can have *multiple* such tools, each of which has their own concept model. You can write a tool that takes Java-style iterators and generates code for STL-style iterators. Or vice-versa. So I fail to see the problem here. -- 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 email 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/bb8f21fb-3f6c-4905-a8b9-688cb15f5e30%40isocpp.org. ------=_Part_18563_1747966124.1528051621776 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, June 3, 2018 at 1:01:32 PM UTC-4, Omer Rosler w= rote:
On Sunday, June 3, 2018 a= t 4:59:34 AM UTC+3, Nicol Bolas wrote:
> On Saturday, June 2, 2018 at= 7:57:30 PM UTC-4, Omer Rosler wrote:
>
>
>
> Th= e problem with second approach the user now has to remember two versions of= the same concepts: one to use and one to implement.
>
>
&= gt; How many times have you used an iterator? I bet it's several orders= of magnitude more often than you've written one.
>
>
= > Yes, your library has two concepts. But they aren't two versions o= f the same concept. There's the Iterator concept, and there's the T= hingThatThisToolTurnsIntoAnIterator concept. Those aren't the same= thing; indeed, more likely than not, they are quite dissimilar. They have = different interfaces and different purposes.
>
>
> User= s don't have to remember the ThingThatThisToolTurnsIntoAnIterator = concept, because they simply don't use it very often. When they need to= use it, they'll look up what it does and how it works. What they'r= e going to remember is Iterator, because that's what they're using = most of the time.

Well the iterator comparison for the ratio of uses/impl= ementations is not fair as this is not the case for every concept library o= ut there.

T= here is a second problem with this separation into two concepts:
Conside= r a customization point in the users' concepts that is given via a trai= ts class.
If that customization is not given by the ThingThatTurnsIntoMy= Concept (then this concept also has a traits class) then users and implemen= ters use different customization points which costs the library in a lot mo= re metaprogramming pain just because it uses concepts.


Let's be more specific about the problem, using iterato= rs as kind of a model for the idea.

Iterators have= a lot of interfaces. This makes them easy to use, so those interfaces prov= ide value. So that's your "consumption concept", one that'= ;s optimized based on the usefulness to the code using such objects.

But implementing iterators, particularly from range-= like starting points, is painful. It often requires a lot of repetition or = writing a lot of boilerplate. You could imagine a far more simplified inter= face. But you don't want users to use that interface, because th= e interface is less usable than the Iterator interface. This is your "= implementation concept".

These two concep= ts have nothing to do with one another. They are two different conce= pts for two different users with two different use cases. The only associat= ion between them is that there is some piece of metaprogramming code which = takes objects which abide by the implementation concept and generates objec= ts for the consumption concept.

But this is merely= a helper tool for the consumption concept. It is not a fundamental = or essential part of that concept. After all, nobody is forcing you = to use this particular tool. If you want to write your Iterator type withou= t help, you certainly can do so. As long as you conform to the consumption = concept, you're fine.

Not only that, you can h= ave multiple such tools, each of which has their own concept model. = You can write a tool that takes Java-style iterators and generates code for= STL-style iterators. Or vice-versa.

So I fail to = see the problem here.

--
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/bb8f21fb-3f6c-4905-a8b9-688cb15f5e30= %40isocpp.org.
------=_Part_18563_1747966124.1528051621776-- ------=_Part_18562_1769981434.1528051621775-- .