220 36508 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Currying or Partial Application Date: Sat, 6 Jan 2018 15:44:26 +0000 Lines: 162 Approved: news@gmane.org Message-ID: References: <835cc86a-2e6c-4e17-aec7-4f16cf8b085f@isocpp.org> <7A4EE214-FE5B-4EC2-BE9E-23522F55EE5B@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c1418cab408705621d707f" X-Trace: blaine.gmane.org 1515253356 27448 195.159.176.226 (6 Jan 2018 15:42:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 15:42:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBXG5YPJAKGQEAXJGN4Q@isocpp.org Sat Jan 06 16:42:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXqc5-0006MJ-VG for gclcip-std-proposals@m.gmane.org; Sat, 06 Jan 2018 16:42:26 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id c85sf3576804oib.13 for ; Sat, 06 Jan 2018 07:44:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515253469; cv=pass; d=google.com; s=arc-20160816; b=sSpu+NnorEwuq9/3ocE/HM6RH9wMlIzwd+9/FkkHZO8vWL/Gy/QKBY6n0W23z2dic8 +qs0w+ARPka74AiwEH/H4MJRcm6bsIt+BQoEcj4uzFBD6ZRMSrDbIaSxgklAE1U3nWNn nelw1HqBijhMpMAwSqvO4ChjAweWbZH2x7HtGVev/ivw9pusWp4sw68Lc7fTj9M1mAWT Gr+DqjawOOnAYDM10/NMLYUNBKqo/Qy7tmRfdvN9Yr9JAy2BDqAfYteH7Y9ni7sMYyp+ oUw6Pa9LzTiA/panIPV8ubSGKwFj4WAX+PC7F7TBs2GHUffhnBqEkzkstHQ4cd82LLz2 E04g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=/hfZT8aiyRZwjcNVS1xHQVKLEeYtYQSyVgrHwWxMiS8=; b=iPNuiV3G1BctnG2hL9k/16ybccwOMkToN0362l1F1Iteelkam/zZCyjErB8BE7KsPG lbts1ypiqEEKXNBi4wtLRWM4Ok9eqvuIFTA7fz2SPKeUFBkAXnaOxpydkYolJUuWh88b t7dq9mbBLSSQgKlEVzTPjbNLM4pgA6q03Yd/pSHHS8tW+K1lqoHxvfZja+gbjllZKRbM Sa5rsFkZwKy+7T2VANaafIiQ0gTpTR5ABmr1aXJQf7ik1m1d0TS1KJOU3H0miehY1emS AbVU/1B7MMW0b6yB07z+CwiDjDXATPvm9JVkjhH4ThxYxTRttXOtdIuHN+MHHVJKQeIQ RESg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m1oB8qt/; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com 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:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/hfZT8aiyRZwjcNVS1xHQVKLEeYtYQSyVgrHwWxMiS8=; b=P73n7/NN5//AmPXgPX3W7iKq0UJP/hWsyQj19EOdwjfnxhuF5qVvMwE1jSs3791SFZ rajBaXOafBx6Rafe4oXojhCn2m/7I4jA6HuxWJF5G6Rd2ikEf78Y6j43nugexHomLt2f 6NaZwFuuJSIneEb7DdSikCPBPG5l4OvjIiV6OY5awjKlXo9HzYUrvuoxJYrX6lzcS3ib uKQRaM4LqYueULv1drb0Rdc402Yh72Y1t4ML7W7gZugg3rfKqsiI7eomD39Yu1WXbWSj WGPa9N98nrhAarY0lD7epYiKMS4fRxFff+KlNrpEFIHWNHIy6YxYojrRmqWVHnoMxlFx 1+Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=/hfZT8aiyRZwjcNVS1xHQVKLEeYtYQSyVgrHwWxMiS8=; b=X0L35C1sD7QtoyLD0mJ5+DIvjpKbRJUunCggWphJRUyMm8ZzGxiRbWIhYkwMhONR0t C0avhrt+7YsoboyHuVqt4NvEfyp8WHvxunDWZenCDb88fwl2l2ZExy4d0LpKqVrlKjyz vhoUm1Xb9D66WMPxEOVB5NxArp+aXsvGN7TE25QGkOB2zKwydUcULqAEpgonm8tiBphD pLLUDTbpe/8pk5gLRrcV9EWqzRKcz+Y4AQmOsUTYsslvFTNr18WfeHd+lYZgWQTiGoKI AgA6Ov21MOkq6Sir3Cg8ED6r3+Ee8NlHUFs3V53HqY0+/hHmUvSJnPj+jC9742uUu/JK Te6w== X-Gm-Message-State: AKGB3mLiHwWIUzHNt5etYfI97vn5jB9P3mEU485wmHUpY3VEk61bEQ+R sSu7pHv5drkROZTSNZ99qiHTlw== X-Google-Smtp-Source: ACJfBot2cTfHTHvO5CzVQXBJyE9Nf84V+lfN2wO4BtM42UUxYl0fU592BVFRFprbAt3xwpS2bEmRsQ== X-Received: by 10.202.222.134 with SMTP id v128mr3117293oig.51.1515253468985; Sat, 06 Jan 2018 07:44:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.78.211 with SMTP id c202ls1332369oib.2.gmail; Sat, 06 Jan 2018 07:44:27 -0800 (PST) X-Received: by 10.157.10.7 with SMTP id 7mr3622820otg.69.1515253467931; Sat, 06 Jan 2018 07:44:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515253467; cv=none; d=google.com; s=arc-20160816; b=ekdjkcjYLiroDpfyMF8jTMG9gkCGXIOgVa1CNmGH6gSGYonnxlbEddwguilniPtUls P3AkS42hBEBt9BaB0ttGs1BTlQa5JOLSRjCNzCGkRLfAIvaAoyrX/+sNh0x3nj6/DwV6 doY9A/Js6VxyVCBgELIayjOQZ+yzZsyNS8RFnwLZXwW6IUDKAIZBqRCSdA+j8WGCPJYR quVrTw8vXkXexeQRiYcSKkMF94BBe97O1a2xnljbXsNKOdKY4i18fwr5OlpZjn03cYcJ yt5USiRWPTCmtp0gkPXm+R93B3O8gzn63lIh+ImsoIQN9JrKFryr8GfyF9MZH1UB5CYC 1ImA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=QKyKswgLlo9Fm9w1Oj5e0+XyQfR8kbsgAe+/Ax4dbAo=; b=sdxH/A5M29INXF9w8JCOX8M7SCxWJLfQS0hRYhBMqfhKsTX6dXh5Lc36UvFM8OFhDm 50GpetaGpH7UGUKwF1UBBCSGkU7mk5s9uK09Gv3upq7VrxlYS5puPZBBvnLxins+qoZp txLaIQnWJPI4jdVCQ74h+TwSZQtVkBfhytUfSuwrUQtiwed79rCapK7qN5FZS0HrV8en 9hCu9zDVN7WF15ZRhdqAEHekND8cnEC7hetB17Br2jJ24pwSVmiSnEvOUtGaKm07VwlO 2dStHFAZJFzvfByPsLs2qrZc0G0n/eGT9ElT+v6fXTOieOKwXWHbHy/DAhMyP5tNrnYj RYsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m1oB8qt/; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 73sor2795612oth.153.2018.01.06.07.44.27 for (Google Transport Security); Sat, 06 Jan 2018 07:44:27 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.157.62.230 with SMTP id b93mr4007595otc.346.1515253467396; Sat, 06 Jan 2018 07:44:27 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sat, 6 Jan 2018 07:44:26 -0800 (PST) In-Reply-To: <7A4EE214-FE5B-4EC2-BE9E-23522F55EE5B@gmail.com> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m1oB8qt/; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=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:36508 Archived-At: --001a11c1418cab408705621d707f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I love the functional direction of template metaprogramming and I certainly support more functional concepts in the core language. Partial application is nice, and the general idea of implanting that into C++ is something I support. A key feature that you're avoiding here is that of flipping parameters so you can pre-fill the 1st and 3rd parameter and return a function accepting the second parameter and returning the fully evaluated expression - I think this should be a key part of your proposal. Limiting the partial application abilities because of some arbitrary parameter order would be rather frustrating/ I don't think there's any point in defining the function any differently from a normal function (i.e. parameters in different sets of parentheses). If you can utilise partial application at all, then I believe that there is no need to restrict it to functions defined in a very specific way, especially when we already have so many libraries that declare functions in the usual way. Rather than having special syntax at all, it'd first make sense if you can explore the idea of wrapping this in some kind of existing structure. For example, a class encapsulating a function call, where each call recursively produces a sub-class expecting the next parameter until the class with only one remaining parameter, which returns the final result upon the operator() call. You'd stand a *much *better chance doing it that way than changing the underlying language. Fortunately there are already some minor efforts towards this, e.g. https://vittorioromeo.info/index/blog/cpp17_curry.html - *also* make sure you look at std::bind, as it is quite relevant here. On Sat, Jan 6, 2018 at 3:13 PM, Jonathan Coe wrote= : > Do you have an example of how this would allow one to re-write code in a > more maintainable way? I=E2=80=99m not familiar with Scala or the advanta= ges that > partial application can bring. > > Thanks > > Jon > There is a lot of beauty to be found, but at the same time it introduces a different approach to thinking about problems. Here's an immediate example from the above link that is already pretty nice (although it CAN be done with lambdas, more complex examples get ugly fast): std::vector names{/* ... */} auto find_in_names =3D curried_find(std::begin(names))(std::end(names)); auto jack =3D find_in_names("Jack");auto rose =3D find_in_names("Rose"); --=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/CAC%2B0CCNuADCqfhgtS60vpKvnggww1BQC9xVwAPrTBx%2B= _CDcapA%40mail.gmail.com. --001a11c1418cab408705621d707f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I love the functional direction of template= metaprogramming and I certainly support more functional concepts in the co= re language. Partial application is nice, and the general idea of implantin= g that into C++ is something I support.

A key feature that you'r= e avoiding here is that of flipping parameters so you can pre-fill the 1st = and 3rd parameter and return a function accepting the second parameter and = returning the fully evaluated expression - I think this should be a key par= t of your proposal. Limiting the partial application abilities because of s= ome arbitrary parameter order would be rather frustrating/

I don= 9;t think there's any point in defining the function any differently fr= om a normal function (i.e. parameters in different sets of parentheses). If= you can utilise partial application at all, then I believe that there is n= o need to restrict it to functions defined in a very specific way, especial= ly when we already have so many libraries that declare functions in the usu= al way.

Rather than having special syntax at all, it'd first mak= e sense if you can explore the idea of wrapping this in some kind of existi= ng structure. For example, a class encapsulating a function call, where eac= h call recursively produces a sub-class expecting the next parameter until = the class with only one remaining parameter, which returns the final result= upon the operator() call. You'd stand a much better chance doin= g it that way than changing the underlying language. Fortunately there are = already some minor efforts towards this, e.g.=C2=A0https://vittorioromeo.info/index= /blog/cpp17_curry.html - also=C2=A0make sure you look at std::bi= nd, as it is quite relevant here.

On Sat, Jan 6, 2018 at 3:13 PM, Jonathan Coe <jo= nathanbcoe@gmail.com> wrote:
Do you have an example of how this would allow one to re-write code in a= more maintainable way? I=E2=80=99m not familiar with Scala or the advantag= es that partial application can bring.

= Thanks

Jon

There= is a lot of beauty to be found, but at the same time it introduces a diffe= rent approach to thinking about problems. Here's an immediate example f= rom the above link that is already pretty nice (although it CAN be done wit= h lambdas, more complex examples get ugly fast):

std::vecto=
r<std::=
string> names{/* ... */}

auto find_in_nam=
es =3D=20
    curried_find(std:=
:begin(names))<=
/span>(std::end<=
span style=3D"color:rgb(128,128,48)">(names));

auto jack =3D find_in_names("=
Jack");
auto rose =3D find_in_names("=
Rose");

--
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/CAC%2B0CCNuAD= CqfhgtS60vpKvnggww1BQC9xVwAPrTBx%2B_CDcapA%40mail.gmail.com.
--001a11c1418cab408705621d707f-- .