220 24441 article Path: news.gmane.org!not-for-mail From: Sam Kellett Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [tuple] extracting tuples out of a tuple Date: Wed, 17 Feb 2016 09:40:24 +0000 Lines: 124 Approved: news@gmane.org Message-ID: References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> <6e02dbfe-01f3-4840-92ab-bcc8f7824348@isocpp.org> <586249ad-b4ae-4e40-bdf7-344a641ad4c9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114020d813f364052bf40a9b X-Trace: ger.gmane.org 1455702030 24570 80.91.229.3 (17 Feb 2016 09:40:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 09:40:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDY6DWXBQIPRBCMASG3AKGQE5BWLWSA@isocpp.org Wed Feb 17 10:40:29 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVyax-0003Km-0C for gclcip-std-proposals@m.gmane.org; Wed, 17 Feb 2016 10:40:27 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id g62sf5505909wme.1 for ; Wed, 17 Feb 2016 01:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=uUFU5R5ndfM5s3wOxTPgb2rVIee4MykS7KwUvYqrUr4=; b=VlOnZ2B/BMm/RbujMsfrpcvG7HqiUixFJwb0anJ+i7AXSyKuq4NnHaFknPFZgikcUx ZR98A/Jw0OjOX5qDmP9YhDp1mibLWRSdkhVy3iYKVBx94uo8UA5BkhC1vlHwZkNwWhLK sg02RIuO+w5meUX/gGpxkfyvXsBgagOKynLgZzcEKl/U04YhM9wJo6X8Vzsm00Dwx4PP RPqxx+ReLjU5EyBkRl9hjoi5ZfV+gGtKjZXvC8tXNtJf2PSR6hj9ZYgk8hH8SryOIFcL Iwvn790ERARRZMgPOdeTcHGGZsnFyHw1Lrr7tGOquXlbKS1/fMOluekSmRv62aEiqv3u ucWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=uUFU5R5ndfM5s3wOxTPgb2rVIee4MykS7KwUvYqrUr4=; b=JOmTeSJ6ImSYVsMpAsgUmP3NiCfkzN+pXNMY+Vi97b6isPFkZMA8+LyKcj2Q9Lpr6W ws+2FJMs3QW+1efEM3ww+9f9bhcG3WlcajEfD/wUzrmkA6OanXMJDwIHGKcWN5lKflD1 UrCnO3RTOao0BBTvZlLXyZvMa25ix+A+1W4+i6VP+V0Yt1w7IHT3+YfxpxNuCbBmuP3m 8WegdhSlMgmK3pMpZJ8wmNEMjhSnJelLc6XweAUrjP0ex9qIhURgM0jd+1/4pYEgUBIG X2VzYKQCzycLnizK3KxGxThOm6V/LYsQ8g0ueBdYdTNW/VVd2Cgo9ztMnVdybMyrqtPw i0Ng== X-Gm-Message-State: AG10YOSEtC1vn5ikmbz9zAUnNlTWaE9Oky/CakVR3yGrBU+Nw9kEzZgk/SC3Omw6AtcAzA== X-Received: by 10.25.23.105 with SMTP id n102mr84806lfi.9.1455702026388; Wed, 17 Feb 2016 01:40:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.0.144 with SMTP id 138ls866079lfa.19.gmail; Wed, 17 Feb 2016 01:40:24 -0800 (PST) X-Received: by 10.112.161.198 with SMTP id xu6mr253055lbb.131.1455702024759; Wed, 17 Feb 2016 01:40:24 -0800 (PST) Original-Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com. [2a00:1450:4010:c07::235]) by mx.google.com with ESMTPS id e202si288201lfg.155.2016.02.17.01.40.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2016 01:40:24 -0800 (PST) Received-SPF: pass (google.com: domain of samkellett@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) client-ip=2a00:1450:4010:c07::235; Original-Received: by mail-lf0-x235.google.com with SMTP id l143so6920310lfe.2 for ; Wed, 17 Feb 2016 01:40:24 -0800 (PST) X-Received: by 10.25.144.80 with SMTP id s77mr287519lfd.6.1455702024644; Wed, 17 Feb 2016 01:40:24 -0800 (PST) Original-Received: by 10.114.185.201 with HTTP; Wed, 17 Feb 2016 01:40:24 -0800 (PST) In-Reply-To: <586249ad-b4ae-4e40-bdf7-344a641ad4c9@isocpp.org> X-Original-Sender: samkellett@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of samkellett@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) smtp.mailfrom=samkellett@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:24441 Archived-At: --001a114020d813f364052bf40a9b Content-Type: text/plain; charset=UTF-8 On 17 February 2016 at 03:28, Nicol Bolas wrote: > [snip] > > It's not really that it's terse; that's not what attracts me to tuple > expansion. What matters most to me is that the code looks as much like > normal code ought to look. > > This is also what repels me from your ranges example. > > Most programmers know what `outer(inner(value))` does. They can understand > that by inspection, and its meaning is clear. Most programmers understand > what `inner(value) + inner(value2)` means. > > Hana code is not obvious, not to someone who isn't familiar with template > metaprogramming and such techniques. > > While an unsuspecting programmer may not understand exactly what the `...` > and `[:]` parts mean, they can still look at `outer(inner([:]value)...)` > and see that `inner` will be called, followed by `outer`. It carries the > same physical structure and code layout of the simple and obvious case. It > may be more complex under the hood, but the user is not exposed to it. > with all due respect you seem to be taking your own opinion on this and applying it to all. while that could be ok on it's own it's clashes with the fact that you also take louis' opinion on this and applying it to just him. do you have a study / survey that confirms this? my personal opinion is that hana's is much much much more obvious (the lambda version of the example specifically), in no short reason because it's interface is based on the existing standard library. why do we need two syntax's in one language when we can do it all with one? > When looking at `hana::on(inner, outer)`, they have absolutely no idea > what that means. Not without looking up the docs. There is no intuitive > grasp of what's going on. > again you kinda need proof that this isn't also true for your example. have you shown it to people blind (without knowledge of the problem domain) and have they been able to deduce what it means? also yours appears to be inherently ungoogle-able. assuming i don't understand either syntax, for louis' i type into google 'c++ hana::unpack', what do i type to find the reference pages for yours? -- --- 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/. --001a114020d813f364052bf40a9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 7 February 2016 at 03:28, Nicol Bolas <jmckesson@gmail.com> wrote:
=C2=A0[snip]<= br>

It's not really t= hat it's terse; that's not what attracts me to tuple expansion. Wha= t matters most to me is that the code looks as much like normal code ought = to look.

This is also what repels me from your ranges example.
Most programmers know what `outer(inner(value))` does. They can understan= d that by inspection, and its meaning is clear. Most programmers understand= what `inner(value) + inner(value2)` means.

Hana code is not obvious= , not to someone who isn't familiar with template metaprogramming and s= uch techniques.

While an unsuspecting programmer may not understand = exactly what the `...` and `[:]` parts mean, they can still look at `outer(= inner([:]value)...)` and see that `inner` will be called, followed by `oute= r`. It carries the same physical structure and code layout of the simple an= d obvious case. It may be more complex under the hood, but the user is not = exposed to it.

with a= ll due respect you seem to be taking your own opinion on this and applying = it to all. while that could be ok on it's own it's clashes with the= fact that you also take louis' opinion on this and applying it to just= him.

do you have a study / survey that confirms this? my= personal opinion is that hana's is much much much more obvious (the la= mbda version of the example specifically), in no short reason because it= 9;s interface is based on the existing standard library. why do we need two= syntax's in one language when we can do it all with one?
=C2=A0
When looking at `ha= na::on(inner, outer)`, they have absolutely no idea what that means. Not wi= thout looking up the docs. There is no intuitive grasp of what's going = on.

again you kinda need pr= oof that this isn't also true for your example. have you shown it to pe= ople blind (without knowledge of the problem domain) and have they been abl= e to deduce what it means?

also yours appears to be inher= ently ungoogle-able. assuming i don't understand either syntax, for lou= is' i type into google 'c++ hana::unpack', what do i type to fi= nd the reference pages for yours?

--

---
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= /.
--001a114020d813f364052bf40a9b-- .