220 24419 <6e02dbfe-01f3-4840-92ab-bcc8f7824348@isocpp.org> article Path: news.gmane.org!not-for-mail From: Louis Dionne Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [tuple] extracting tuples out of a tuple Date: Tue, 16 Feb 2016 12:21:28 -0800 (PST) Lines: 440 Approved: news@gmane.org Message-ID: <6e02dbfe-01f3-4840-92ab-bcc8f7824348@isocpp.org> References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_842_437578892.1455654088926" X-Trace: ger.gmane.org 1455654097 18507 80.91.229.3 (16 Feb 2016 20:21:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Feb 2016 20:21:37 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCV3HSWWRMMRBSUJR23AKGQEHZY4DGI@isocpp.org Tue Feb 16 21:21:37 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVm7o-0004Jz-Pn for gclcip-std-proposals@m.gmane.org; Tue, 16 Feb 2016 21:21:33 +0100 Original-Received: by mail-ig0-f200.google.com with SMTP id rs1sf327764918igb.3 for ; Tue, 16 Feb 2016 12:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type: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=Sh+kh/b2WdPzfO9Y9n3T9z7HDB19N6jXXmJlNFdwugQ=; b=tq66lk0zejwcmxwe6WiL/FQKofNaO2stUp32vqeUZvrzUs1tmlUN+mw4bv9Myka9pz vWJ7JCMj7vLg9uiQ7WRfFjQjBNF+hxydRsnF5mLVxhD2j865NZriiGdKMltpKpHli5l/ jHrP4VaUeXL3Fx1AZ0ZLqBmAD7ft450S6GHq/YeQdQESuFpMrXyNtSXyyNh+oiMmYqFh KOrVvH9TK0eBEE7+BybsCFXT0BkSWNu27ImzVSa4pRhCZl3leAlDaBlCAvNuMXXXlEI6 /iWjlgR40tM9uqbvU+i8ILl+uDVJqBxF3edDQ5g/HqsdTOX4Tr4IN8oOBX05kj9nyGXW vYng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type: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=Sh+kh/b2WdPzfO9Y9n3T9z7HDB19N6jXXmJlNFdwugQ=; b=dDUgTTmxAcx064FDYd/2oEJ42G/i4kDDfYHCbrSLzSg3b0wls/ARiEwHYjmeJaiTIK 5BgvjYHYTOPVEuZxHe5StfwUNw16LFDbPYgSivK6O4g1qm0EDiGXza0BM9UMjpMopu/R Agh33/HVwslAPkyZmTVz/9ZIvnmWzSiHSvngQYoUqJYqufrVYbbFZ9LJiEMwDm1VolzT L6ChuwJQJf9RkJXW0cKW8tS0i61oaQPRp2CBah3SSdxEkOOSG+StJNV/o5jlbLzWSW/A ihUYkn61QVRVN6F9WGmnVH+5G6X25XqSV2KWtBAEYVhNooP6KBTFTO6Ex2Bi5ggo7wwF bc0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type: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=Sh+kh/b2WdPzfO9Y9n3T9z7HDB19N6jXXmJlNFdwugQ=; b=DTchtDUR6p2KUkpTv5eLy69Slzn36BGMlSVDoBo4ybcl0Mw97HxJYP1czBmvE6kG9w YbLDv5HQOqrPaAs54fzbV3RbyoM0qd5qxuzSUcU/Xi1eFiOZrVwkRattDE+UhEl5PjxT a/oJq/Pd9O/rDAIoTp6gtDu0P1mbcT6Q0xg33zVNOJoHmdcekSZ/24A4fSj5OXOhnsOs 5ey9NIitNm5KYCodEXbJBvVwqmeQSuoQqkw9kzaWqyTxIktzaXI4zxmuoEe34GrYmi5W jQCcC6BQkb6WsJyD8IblrYyWoN4wpl2LDd8Uy7JFWBvO65GKtj0qbjE48nv25vgJ+/oO yr5Q== X-Gm-Message-State: AG10YOSlOEUfBC66avE43VvR7K/h1rECSyBd+XyqRyzqrzYWpFEaa2hmWQYdeyxOshJeaA== X-Received: by 10.107.8.216 with SMTP id h85mr25103045ioi.0.1455654091409; Tue, 16 Feb 2016 12:21:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.131.166 with SMTP id on6ls1172648igb.6.canary; Tue, 16 Feb 2016 12:21:30 -0800 (PST) X-Received: by 10.50.111.100 with SMTP id ih4mr284926igb.3.1455654090208; Tue, 16 Feb 2016 12:21:30 -0800 (PST) In-Reply-To: X-Original-Sender: ldionne.2@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:24419 Archived-At: ------=_Part_842_437578892.1455654088926 Content-Type: multipart/alternative; boundary="----=_Part_843_1212118557.1455654088927" ------=_Part_843_1212118557.1455654088927 Content-Type: text/plain; charset=UTF-8 On Monday, 15 February 2016 21:10:52 UTC-5, Nicol Bolas wrote: > On Monday, February 15, 2016 at 6:22:24 PM UTC-5, Louis Dionne wrote: > > Hi, > > > > I'd like to quickly chime in to drop a link to Boost.Hana [1] (which I'm the > > author of, for full disclosure). There seems to be quite a bit of discussion > > about adding language features to manipulate packs and tuples, when a lot of > > this could be done in a library. Hana's purpose is specifically to manipulate > > tuples (and more generally heterogeneous containers) by providing std-like > > algorithms to operate on them. > > > > Reading the comments here, I just don't see the need for a new language > > feature for manipulating parameter packs. Instead, I think we need proper > > standard library features to manipulate tuples with a high level of > > abstraction. > > That's like saying, "Why do we need lambdas in the language? > We have Boost.Lambda!" > > Indeed, I seem to recall Boost.Lambda being one of the impetuses for getting > language-based lambdas. BLL was basically proof that you couldn't do lambdas > as a library. It said, "Look, this is the best the language can do as is: > here's what you get, here's what you have to do to implement it, here's how > ugly user-code looks, and here are all of the places where it breaks down". It's significantly different in the level of cumbersomeness of using Boost.Lambda vs language lambdas, and using Boost.Hana vs what you're proposing. Language-level lambdas are an obvious relief because using Boost.Lambda is a PITA. As you'll hopefully see below, the status quo is workable if you use a proper library. > In that regard, libraries like Fusion and Hana are perfect examples of why > tuple unpacking needs to be a language feature. > > Show me the Hana code for this: > > outer(inner([:]tpl)...) > > This calls `inner` on each element of the tuple, then pipes the result into > the call to `outer`. It works exactly like parameter packs too, so if `tpl` > were a pack, you just drop the `[:]` syntax and it works. With Hana, you'd write hana::unpack(tpl, hana::on(inner, outer)); or you could also write hana::unpack(tpl, [](auto ...x) { return outer(inner(x)...); }); Basically, `unpack` is just `std::apply` but with the arguments reversed. > Show me the Hana code for this: > > auto x = inner([:]tpl) + ...; > > This simply calls a function on each element of the tuple and takes the sum > of the results. Again, it works like parameter packs, so it reuses existing > knowledge. You could write auto x = hana::fold_left(hana::transform(tpl, inner), std::plus<>{}); or equivalently auto x = hana::fold_left(tpl, [](auto a, auto b) { return a + inner(b); }); `hana::fold_left` is just like `std::accumulate`, and `hana::transform` is just like `std::transform`. To me, the fact that we're using algorithms that we already know from runtime programming is a good thing, whereas your proposed notation requires yet another special thing to learn. Of course, your proposed syntax wins here because it was designed precisely for these use cases, but I hope you'll agree that a library-based solution is nowhere near the ugliness of good old Boost.Lambda expressions. > Oh, and show me the Hana code for this: > > struct Data > { > int i; > float f; > double d; > }; > > Data d = ...; > outer(inner([:]d)...); > > It's the same as the first example, only using an aggregate. Ah! That's a good one! Here's how you would write it: BOOST_HANA_DEFINE_STRUCT(Data, (int, i), (float, f), (double, d) ); Data d = ...; hana::unpack(hana::members(d), hana::on(inner, outer)); Really, the only cumbersome thing here is the definition of the struct. And I do agree that we need a proper way of introspecting user defined types, and __this is certainly not the job for a library__. However, if we designed a proper way of introspecting user-defined types, it would then be very easy to plug this into the customization point of a library. The challenge of bringing compile-time introspection to C++ is obviously something that needs to be done, but I think that's out of the scope of the current discussion. > [...] > > > If properly designed, that could be much more flexible than > > a language feature in the long term, when we realize that we're missing > > something else. Just to give you a glimpse: how would you reverse a parameter > > pack? How would you sort a parameter pack based on a compile-time predicate? > > I don't see how these slicing proposals are of any help, yet this is a very > > real use case for metaprogramming. > > > > Instead, I think we need to carefully design a STL for metaprogramming (with > > customization points where it makes sense), and then let users build on top > > of that. And if you're worried about compile-times being too long with a > > library-based approach, this can be tackled with a few well-chosen compiler > > intrinsics (see this article [2]). > > So instead of having language support for unpacking tuples, you want > language support for... some low-level stuff that can be used to build > a library? > > No thanks; I'll take the simple and easy-to-use feature over the huge and > complex STL-like thing. The problem I see is that to get rid of a more general library solution that you deem too complex, you propose adding a language feature that will only tackle a subproblem. You're basically offloading complexity onto the language itself, which I think is harmful. On Tuesday, 16 February 2016 11:07:30 UTC-5, Matthew Woehlke wrote: > On 2016-02-15 21:10, Nicol Bolas wrote: > > On Monday, February 15, 2016 at 6:22:24 PM UTC-5, Louis Dionne wrote: > >> Reading the comments here, I just don't see the need for a new language > >> feature for manipulating parameter packs. Instead, I think we need proper > >> standard library features to manipulate tuples with a high level of > >> abstraction. > > > > That's like saying, "Why do we need lambdas in the language? We have > > Boost.Lambda!" > > [...] > > > > Show me the Hana code for [many examples]: > > Wow... thanks, Nicol! Exactly what I would have said, only better :-). > > >> If properly designed, that could be much more flexible than > >> a language feature in the long term, when we realize that we're missing > >> something else. Just to give you a glimpse: how would you reverse a > >> parameter pack? How would you sort a parameter pack based on a compile-time > >> predicate? > > *Simple* unpacking solves a basic problem that is hard to solve as a > library solution (see previous discussion at > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/PghsmqN1cAw/0Q1V-22lFAAJ): > > foo([:]tl1..., [:]tl2...); You could write hana::unpack(hana::concat(tl1, tl2), foo); Sure, it suffers some limitations explored in your link above, but frankly I would call out these limitations as being academic for the most part. Definitely not something that justifies a language feature on itself, IMHO. > [...] > >> I don't see how these slicing proposals are of any help, yet this > >> is a very real use case for metaprogramming. > > That's... nice. Many of the example uses for unpacking and even slicing > *do not* involve metaprogramming. Do you have such examples for > reversing and sorting? I guess that's just a misunderstanding on what exactly is to be considered metaprogramming. As for use cases, sorting can be useful if you e.g. have computations with compile-time dependencies and want to run them in the right order. You sort them at compile-time and then execute the computations. Or it could also be sorting types by alignment as a runtime optimization. Sorting is arguably more useful than reversing in my experience, but others like `find_if` are even more important yet we don't have any good way of doing it. Let it be clear that I understand that the problems you're talking about for unpacking are real, and we need a solution (language or library-based). My discomfort lies in the fact that I'd like to see a carefully designed system that tackles more than just unpacking and slicing tuples, but that has a wider scope and unifying vision. And if unpacking/slicing ends up needing a language feature in this __designed__ system, then I'll be all for it. However, what I think we need to avoid is to introduce yet another short sighted feature that will quickly reach its limitations, and that we'll then need to patch with another short sighted feature later on. Regards, Louis Dionne -- --- 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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_843_1212118557.1455654088927 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, 15 February = 2016 21:10:52 UTC-5, Nicol Bolas wrote:
> On Monday, February = 15, 2016 at 6:22:24 PM UTC-5, Louis Dionne wrote:
> > Hi,
> >
> > I'd like to quickly chime in to = drop a link to Boost.Hana [1] (which I'm the
> > author= of, for full disclosure). There seems to be quite a bit of discussion
> > about adding language features to manipulate packs and tupl= es, when a lot of
> > this could be done in a library. Hana= 's purpose is specifically to manipulate
> > tuples (an= d more generally heterogeneous containers) by providing std-like
= > > algorithms to operate on them.
> >
>= > Reading the comments here, I just don't see the need for a new la= nguage
> > feature for manipulating parameter packs. Instea= d, I think we need proper
> > standard library features to = manipulate tuples with a high level of
> > abstraction.
>
> That's like saying, "Why do we need lam= bdas in the language?
> We have Boost.Lambda!"
= >
> Indeed, I seem to recall Boost.Lambda being one of the = impetuses for getting
> language-based lambdas. BLL was basica= lly proof that you couldn't do lambdas
> as a library. It = said, "Look, this is the best the language can do as is:
>= ; here's what you get, here's what you have to do to implement it, = here's how
> ugly user-code looks, and here are all of the= places where it breaks down".

It's signi= ficantly different in the level of cumbersomeness of using
Boost.= Lambda vs language lambdas, and using Boost.Hana vs what you're
proposing. Language-level lambdas are an obvious relief because using
Boost.Lambda is a PITA. As you'll hopefully see below, the stat= us quo
is workable if you use a proper library.


> In that regard, libraries like Fusion and Hana = are perfect examples of why
> tuple unpacking needs to be a la= nguage feature.
>
> Show me the Hana code for thi= s:
>
> outer(inner([:]tpl)...)
>
> This calls `inner` on each element of the tuple, then pipes the= result into
> the call to `outer`. It works exactly like para= meter packs too, so if `tpl`
> were a pack, you just drop the = `[:]` syntax and it works.

With Hana, you'd wr= ite

=C2=A0 =C2=A0 hana::unpack(tpl, hana::on(inner= , outer));

or you could also write

<= /div>
=C2=A0 =C2=A0 hana::unpack(tpl, [](auto ...x) { return outer(inne= r(x)...); });

Basically, `unpack` is just `std::ap= ply` but with the arguments reversed.


> Show me the Hana code for this:
>
> auto = x =3D inner([:]tpl) + ...;
>
> This simply calls = a function on each element of the tuple and takes the sum
> of= the results. Again, it works like parameter packs, so it reuses existing
> knowledge.

You could write

=C2=A0 =C2=A0 auto x =3D hana::fold_left(hana::transform(tp= l, inner), std::plus<>{});

or equivalently

=C2=A0 =C2=A0 auto x =3D hana::fold_left(tpl, [](au= to a, auto b) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return a + inner(b);<= /div>
=C2=A0 =C2=A0 });

`hana::fold_left` is j= ust like `std::accumulate`, and `hana::transform` is
just like `s= td::transform`. To me, the fact that we're using algorithms that
<= div>we already know from runtime programming is a good thing, whereas your<= /div>
proposed notation requires yet another special thing to learn. Of= course,
your proposed syntax wins here because it was designed p= recisely for these
use cases, but I hope you'll agree that a = library-based solution is nowhere
near the ugliness of good old B= oost.Lambda expressions.


> Oh, a= nd show me the Hana code for this:
>
> struct Dat= a
> {
> =C2=A0 int i;
> =C2=A0 float= f;
> =C2=A0 double d;
> };
>
<= div>> Data d =3D ...;
> outer(inner([:]d)...);
&g= t;
> It's the same as the first example, only using an agg= regate.

Ah! That's a good one! Here's how = you would write it:

=C2=A0 =C2=A0 BOOST_HANA_DEFIN= E_STRUCT(Data,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (int, i),
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 (float, f),
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 (double, d)
=C2=A0 =C2=A0 );

=C2=A0 = =C2=A0 Data d =3D ...;
=C2=A0 =C2=A0 hana::unpack(hana::members(d= ), hana::on(inner, outer));

Really, the only cumbe= rsome thing here is the definition of the struct.
And I do agree = that we need a proper way of introspecting user defined types,
an= d __this is certainly not the job for a library__. However, if we designed<= /div>
a proper way of introspecting user-defined types, it would then b= e very easy
to plug this into the customization point of a librar= y. The challenge of
bringing compile-time introspection to C++ is= obviously something that needs
to be done, but I think that'= s out of the scope of the current discussion.


=
> [...]
>
> > If properly design= ed, that could be much more flexible than
> > a language fe= ature in the long term, when we realize that we're missing
&g= t; > something else. Just to give you a glimpse: how would you reverse a= parameter
> > pack? How would you sort a parameter pack ba= sed on a compile-time predicate?
> > I don't see how th= ese slicing proposals are of any help, yet this is a very
> &g= t; real use case for metaprogramming.
> >
> &g= t; Instead, I think we need to carefully design a STL for metaprogramming (= with
> > customization points where it makes sense), and th= en let users build on top
> > of that. And if you're wo= rried about compile-times being too long with a
> > library= -based approach, this can be tackled with a few well-chosen compiler
<= div>> > intrinsics (see this article [2]).
>
&= gt; So instead of having language support for unpacking tuples, you want
> language support for... some low-level stuff that can be used = to build
> a library?
>
> No thanks;= I'll take the simple and easy-to-use feature over the huge and
> complex STL-like thing.

The problem I see = is that to get rid of a more general library solution that
you de= em too complex, you propose adding a language feature that will only
<= div>tackle a subproblem. You're basically offloading complexity onto th= e language
itself, which I think is harmful.

=


On Tuesday, 16 February 2016 11:07:30 UT= C-5, Matthew Woehlke wrote:
> On 2016-02-15 21:10, Nicol Bolas= wrote:
> > On Monday, February 15, 2016 at 6:22:24 PM UTC-= 5, Louis Dionne wrote:
> >> Reading the comments here, I= just don't see the need for a new language
> >> fea= ture for manipulating parameter packs. Instead, I think we need proper
> >> standard library features to manipulate tuples with a h= igh level of
> >> abstraction.
> >
=
> > That's like saying, "Why do we need lambdas in the = language? We have
> > Boost.Lambda!"
> &g= t; [...]
> >
> > Show me the Hana code for = [many examples]:
>
> Wow... thanks, Nicol! Exactl= y what I would have said, only better :-).
>
> &g= t;> If properly designed, that could be much more flexible than
> >> a language feature in the long term, when we realize that w= e're missing
> >> something else. Just to give you a= glimpse: how would you reverse a
> >> parameter pack? H= ow would you sort a parameter pack based on a compile-time
> &= gt;> predicate?
>
> *Simple* unpacking solves = a basic problem that is hard to solve as a
> library solution = (see previous discussion at
> https://groups.google.com/a/isoc= pp.org/d/msg/std-proposals/PghsmqN1cAw/0Q1V-22lFAAJ):
>
<= div>> =C2=A0 foo([:]tl1..., [:]tl2...);

You cou= ld write

=C2=A0 =C2=A0 hana::unpack(hana::concat(t= l1, tl2), foo);

Sure, it suffers some limitations = explored in your link above, but frankly
I would call out these l= imitations as being academic for the most part.
Definitely not so= mething that justifies a language feature on itself, IMHO.


> [...]
> >> I don't see = how these slicing proposals are of any help, yet this
> >&g= t; is a very real use case for metaprogramming.
>
&g= t; That's... nice. Many of the example uses for unpacking and even slic= ing
> *do not* involve metaprogramming. Do you have such examp= les for
> reversing and sorting?

I gu= ess that's just a misunderstanding on what exactly is to be considered<= /div>
metaprogramming. As for use cases, sorting can be useful if you e= ..g. have
computations with compile-time dependencies and want to = run them in the right
order. You sort them at compile-time and th= en execute the computations. Or
it could also be sorting types by= alignment as a runtime optimization.
Sorting is arguably more us= eful than reversing in my experience, but others
like `find_if` a= re even more important yet we don't have any good way of
doin= g it.


Let it be clear that I unders= tand that the problems you're talking about for
unpacking are= real, and we need a solution (language or library-based). My
dis= comfort lies in the fact that I'd like to see a carefully designed syst= em
that tackles more than just unpacking and slicing tuples, but = that has a wider
scope and unifying vision. And if unpacking/slic= ing ends up needing a language
feature in this __designed__ syste= m, then I'll be all for it. However, what I
think we need to = avoid is to introduce yet another short sighted feature that
will= quickly reach its limitations, and that we'll then need to patch with<= /div>
another short sighted feature later on.

= Regards,
Louis Dionne

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_843_1212118557.1455654088927-- ------=_Part_842_437578892.1455654088926-- .