220 13934 <54b13a8a-17b8-4b0e-960b-6fbb06bb0185@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vadim Petrochenkov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comment on N4191 - Folding expressions (Sutton, Smith) Date: Wed, 15 Oct 2014 13:49:27 -0700 (PDT) Lines: 376 Approved: news@gmane.org Message-ID: <54b13a8a-17b8-4b0e-960b-6fbb06bb0185@isocpp.org> References: <543E7CB4.7020003@gmx.net> <543E8241.7060307@irrequietus.eu> <543EC30A.5030103@gmx.net> <543ED027.10509@irrequietus.eu> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_825_1522406545.1413406167639" X-Trace: ger.gmane.org 1413406179 23811 80.91.229.3 (15 Oct 2014 20:49:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Oct 2014 20:49:39 +0000 (UTC) Cc: george@irrequietus.eu To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJOZ3HVXIEBBWF37OQQKGQENOPWQDY@isocpp.org Wed Oct 15 22:49:34 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f198.google.com ([209.85.216.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XeVVh-00080I-Gm for gclcip-std-proposals@m.gmane.org; Wed, 15 Oct 2014 22:49:29 +0200 Original-Received: by mail-qc0-f198.google.com with SMTP id c9sf4156150qcz.9 for ; Wed, 15 Oct 2014 13:49:28 -0700 (PDT) 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:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=/fKWUCaV8WXCAu8PRGhIG8OebXXwwcLoKJ0/YKdLTOU=; b=iOKf0hTQeKGMVJtds92MPRE3zMcncaR1cj0rEnkbn0d+hjLN2i3hovn3bH13zJWZC0 AA+3rwQLgNr2TOU5deZIGKgHpDmY+xim5Qc73fJkye5sSdm17gMZFhwR/0+5taVvLOTL k/KE99s/v+m2hDqGpZ9N1Sd1C423sFhYTqJbGAtaMCgoWcVTG7xCUlUgXD5DCLYXG9kx ztBxGx57P5JHVduW06rUDB+y3y63YlCwN8Ea5wAV/nNfMPfq4WqZLmoGwvNC4MjXUOFT 0eW8bxvhOywarrIqwvP0JGyaPaA2DRB3Vu5s6KUGkunhhYAzUSBEuCxqna8Sqe6yzPSR 3QmQ== 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:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=/fKWUCaV8WXCAu8PRGhIG8OebXXwwcLoKJ0/YKdLTOU=; b=ZLoXP2GaOoBzrw+pGlwgrawNrVcJoKcVS12fBF+8wZ715oR8WpS9iI5GwwQdZGogMe AyOO6His7j2peMxjRaR33lHNX7joxnF70HtX/bytOspi/vdzFqERQDMa2/0iBI2Z6zYr aBqrMUXZrXiGV/dAe++9+5N36tK16liREe0zncSk41+paGGm0/kMaV+NyeluPEDCzVP1 ZWfGTSPx5bhSRukQJbElp3jZ9n6vFMBQoR693s4dFnj4jpbWfPmhVh/6vcwiIcvcmZFo MCKWKG3ikv6LnzXRf6wT2vcSbQAuctG9xdnLuFNShFyES9Fx2ju2T1gYZLTDvEYu+vk5 uFNw== X-Gm-Message-State: ALoCoQkIxg1TFqks2uDJ0v+bxOkUR1Onh0cmpd8OWqRYZcg3vKmsRGPzN51ghIWu6rKO0q78/PqF X-Received: by 10.224.30.133 with SMTP id u5mr9965135qac.8.1413406168706; Wed, 15 Oct 2014 13:49:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.108.139 with SMTP id j11ls483471qgf.33.gmail; Wed, 15 Oct 2014 13:49:28 -0700 (PDT) X-Received: by 10.140.18.133 with SMTP id 5mr29441qgf.17.1413406168021; Wed, 15 Oct 2014 13:49:28 -0700 (PDT) In-Reply-To: <543ED027.10509@irrequietus.eu> X-Original-Sender: vadim.petrochenkov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:13934 Archived-At: ------=_Part_825_1522406545.1413406167639 Content-Type: text/plain; charset=UTF-8 FWIW, I can't recall any precedent in the language where some binary operator can't be trivially substituted with an equivalent named function (except maybe short-circuiting built-in logical operators). Are there any? On Wednesday, October 15, 2014 11:51:20 PM UTC+4, George Makrydakis wrote: > > > On 10/15/2014 09:55 PM, Jens Maurer wrote: > > On 10/15/2014 04:18 PM, George Makrydakis wrote: > > On 10/15/2014 04:55 PM, Jens Maurer wrote: > > I'd prefer not to derail N4191 with additional features > or depend on other proposals. > > It seems your suggestions are purely add-on and should > be handled in a separate paper. > > I agree with your observation on the first one on expanding this to type > parameters (and why not on template-template type ones) being part of a > separate paper (are they going to write it?). > > Probably not. Ask the author to be sure. Otherwise, feel free to > write a paper yourself. > > Unlikely to happen not because I am not equipped to do it but because it > would serve no purpose doing it since there are working on it. I am not new > anymore to how they actually work :) > > Regardless, for when > values are concerned in folding I do not see how N4191 is derailed. > Given that (... op args) and (args op ...) where 'op' is to be an > operator during folding (as Sutton and Smith argue), allowing a function > (constexpr or not) or a lambda to be used in 'op' would seem a rather > good idea: > > (... [](auto x){ /* implementation here */} args) > > (... function_identifier args) > > Such a plain substitution of 'op' for allowing any function identifier / > lambda with the same context of use as 'op', does not depend on other > proposals nor is there an attempt to create another one for what > concerns it. It is a legitimate observation for a likely omission. > > Well, for one, the operators in N4191 are all binary, and that's > how the folding is applied. Your lambda above only has one > parameter, so I don't know how the folding would work there. > Same for functions with more than two parameters. > Are there constraints on the function's return type vs. the > parameter types? > > See my reply almost five (5) hours before your email, I missed a second > parameter while typing and I did send an email for it within twelve minutes > in case that was missed by you. Such catamorphisms over lists obviously > require a binary function, as is the way through which we define left and > right folds in languages having proper support for them. The omission due > to haste was fixed so I think you don't present an argument here for using > this in your defense: > > > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ > : > > (... [](auto x, auto y) { /* implementation here */ } args) > > The *correct comment* in your defense on this would be to ascertain that > 'args' has a sufficient number of arguments inside for the fold to occur, > without bailing out on the last call, not just function arity. The authors > deal with this in their own paper (in a way), while it is obvious that > there are far too many ways to ascertain that. Also, given that there is a > single function identifier to be used there, the type signature is > predictable in case of arguments of the same type, or it can even be > engineered to be in arguments of different types through function template > overloads, to the horror of people not understanding templates (or > concepts). In that case you would not just be doing a fold though, you > would be entering territory best described by the functional programming > paradigm (see Haskell etc) which would be off-topic for us to discuss in > here. > > As for n-ary functions over 2-nary ones as is the case for folds, I remind > that we do have default arguments in functions (one case where an n-ary can > work in a 2-nary), while it is fairly obvious that not even a beginner > would commit the error of calling a function with an improper arity of > arguments, regardless of whether the syntax proposed in N4191 existed or > not. A lot of algorithms in C++'s do have a requirement for > unary functions to be passed for example. I do not think that people cannot > relate to this by precedent nor is it responsible for them to omit such > trivial knowledge. > > Finally, forcing a constraint over C++'s current latent typing approach, > it can be done either through concepts or sfinae based overload resolution > for implementing bounded polymorphism, though the latter option is > obviously one the concepts team would like to avoid. I see no issue here > other than waiting for people to learn the notion of function arity, which > is already in multiple paragraphs of the standard itself and even beginners > are familiar with it. > > Second, I'm pretty certain that "..." adjacent to a binary operator, > surrounded by parens, is pretty unambiguous grammar-wise. > An identifier followed by ... is certainly allowed elsewhere in the > grammar, so I'm a bit more cautious there. > > I think you should think more about it. In essence, they are providing a > new kind of *"binary operator expression"* if you think about it with the > (... ) and ( ...) semantics. Therefore the domain within which ... is > applicable is not ambiguous since there is no identifier prior to the > triple dot in the first case where triple-dot is the first, while in the > second case of folding the triple dot is last following all identifiers, > including those used for inline lambda definition (if ever). I think that > they did this by design. So I really think that you are not presenting a > real argument here against it nor have a valid construct for when () are > used in this domain with the addition of non-operator identifiers. Again, > this is their syntax and yet, it is perfectly suitable for that. > > For the record, the syntax is reminiscent of S-expressions in a way as > well as point-free function application style, though that is not actually > stated by the authors (http://en.wikipedia.org/wiki/S-expression). > > Extending this later to arbitrary functions is an add-on that > doesn't invalidate existing code. Personally, the source code > looks of the "arbitrary function" part of the proposal require > a lot more getting-used-to than the corresponding operator > case. And there is an actual use case for the operator case > in the concepts TS. > > Sure thing, which means that we are in agreement that this does not break > existing or future code. For such a little evident omission on their > behalf, it is of doubtful value to have to wait at least another 4 years > post C++17 to get it as a feature, given that the only way to go through > this using the operators, would be to emulate the result using operator > overloading and/or expression template semantics within the proposed syntax > over the type sequences involved. I doubt that Sutton would love to > encourage such uses. For what concerns constraints, I refer you to my > previous paragraphs as to what *the actual constraint* is. > > It is very nice to see some sort of catamorphism make it as a language > construct in C++, despite we are not yet on full par with general > catamorphisms. I remind that such an addition as the one proposed by N4191, > together with the semantics of pack expansion as we have them right now, > complete an important fold/fmap duo for the purposes of an interesting take > on functional programming style. *So yes, having something more than > operators there is important.* > > Regards, > > George > > > -- --- 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 http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_825_1522406545.1413406167639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, I can't recall any precedent in the language where s= ome binary operator can't be trivially substituted with an equivalent named= function (except maybe short-circuiting built-in logical operators).
A= re there any? 

On Wednesday, October 15, 2014 11:51:20 PM UTC+4= , George Makrydakis wrote:
=20 =20 =20

On 10/15/2014 09:55 PM, Jens Maurer wrote:
On 10/15/2014 04:18 PM, George Makrydakis wrote:

On 10/15/2014 04:55 PM, Jens Maurer wrote:

I'd prefer not to derail N4191 with additional features
or depend on other proposals.

It seems your suggestions are purely add-on and should
be handled in a separate paper.


      

        
I agree with your observation on the first one on expanding th=
is to type=20
parameters (and why not on template-template type ones) being part of a=20
separate paper (are they going to write it?).


      

      
Probably not.  Ask the author to be sure.  Otherwise, feel free =
to
write a paper yourself.

    

    Unlikely to happen not because I am not equipped to do it but
    because it would serve no purpose doing it since there are working
    on it. I am not new anymore to how they actually work :)
    

      

        
 Regardless, for when=20
values are concerned in folding I do not see how N4191 is derailed.=20
Given that (... op args) and (args op ...) where 'op' is to be an=20
operator during folding (as Sutton and Smith argue), allowing a function=20
(constexpr or not) or a lambda to be used in 'op' would seem a rather=20
good idea:

(... [](auto x){ /* implementation here */} args)

(... function_identifier args)

Such a plain substitution of 'op' for allowing any function identifier /=20
lambda with the same context of use as 'op', does not depend on other=20
proposals nor is there an attempt to create another one for what=20
concerns it. It is a legitimate observation for a likely omission.


      

      
Well, for one, the operators in N4191 are all binary, and that's
how the folding is applied.  Your lambda above only has one
parameter, so I don't know how the folding would work there.
Same for functions with more than two parameters.
Are there constraints on the function's return type vs. the
parameter types?

    

    See my reply almost five (5) hours before your email, I missed a
    second parameter while typing and I did send an email for it within
    twelve minutes in case that was missed by you. Such catamorphisms
    over lists obviously require a binary function, as is the way
    through which we define left and right folds in languages having
    proper support for them. The omission due to haste was fixed so I
    think you don't present an argument here for using this in your
    defense:

    

    https:/=
/groups.google.com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/<=
wbr>wxf5VleV6uEJ:

    

    (... [](auto x, auto y) { /* implementation here */ } args)

    

    The correct comment in your defense on this would be to
    ascertain that 'args' has a sufficient number of arguments inside
    for the fold to occur, without bailing out on the last call, not
    just function arity. The authors deal with this in their own paper
    (in a way), while it is obvious that there are far too many ways to
    ascertain that. Also, given that there is a single function
    identifier to be used there, the type signature is predictable in
    case of arguments of the same type, or it can even be engineered to
    be in arguments of different types through function template
    overloads, to the horror of people not understanding templates (or
    concepts). In that case you would not just be doing a fold though,
    you would be entering territory best described by the functional
    programming paradigm (see Haskell etc) which would be off-topic for
    us to discuss in here.

    

    As for n-ary functions over 2-nary ones as is the case for folds, I
    remind that we do have default arguments in functions (one case
    where an n-ary can work in a 2-nary), while it is fairly obvious
    that not even a beginner would commit the error of calling a
    function with an improper arity of arguments, regardless of whether
    the syntax proposed in N4191 existed or not. A lot of algorithms in
    C++'s <algorithm> do have a requirement for unary functions to
    be passed for example. I do not think that people cannot relate to
    this by precedent nor is it responsible for them to omit such
    trivial knowledge.

    

    Finally, forcing a constraint over C++'s current latent typing
    approach, it can be done either through concepts or sfinae based
    overload resolution for implementing bounded polymorphism, though
    the latter option is obviously one the concepts team would like to
    avoid. I see no issue here other than waiting for people to learn
    the notion of function arity, which is already in multiple
    paragraphs of the standard itself and even beginners are familiar
    with it.

    

      
Second, I'm pretty certain that "..." adjacent to a binary opera=
tor,
surrounded by parens, is pretty unambiguous grammar-wise.
An identifier followed by ... is certainly allowed elsewhere in the
grammar, so I'm a bit more cautious there.

    

    I think you should think more about it. In essence, they are
    providing a new kind of "binary operator expression" if you
    think about it with the (... ) and ( ...) semantics. Therefore the
    domain within which ... is applicable is not ambiguous since there
    is no identifier prior to the triple dot in the first case where
    triple-dot is the first, while in the second case of folding the
    triple dot is last following all identifiers, including those used
    for inline lambda definition (if ever). I think that they did this
    by design. So I really think that you are not presenting a real
    argument here against it nor have a valid construct for when () are
    used in this domain with the addition of non-operator identifiers.
    Again, this is their syntax and yet, it is perfectly suitable for
    that.

    

    For the record, the syntax is reminiscent of S-expressions in a way
    as well as point-free function application style, though that is not
    actually stated by the authors (http://en.wikipedia.org/wiki/S-express=
ion).

    

      
Extending this later to arbitrary functions is an add-on that
doesn't invalidate existing code.  Personally, the source code
looks of the "arbitrary function" part of the proposal require
a lot more getting-used-to than the corresponding operator
case.  And there is an actual use case for the operator case
in the concepts TS.

    

    Sure thing, which means that we are in agreement that this does not
    break existing or future code. For such a little evident omission on
    their behalf, it is of doubtful value to have to wait at least
    another 4 years post C++17 to get it as a feature, given that the
    only way to go through this using the operators, would be to emulate
    the result using operator overloading and/or expression template
    semantics within the proposed syntax over the type sequences
    involved. I doubt that Sutton would love to encourage such uses. For
    what concerns constraints, I refer you to my previous paragraphs as
    to what the actual constraint is.

    

    It is very nice to see some sort of catamorphism make it as a
    language construct in C++, despite we are not yet on full par with
    general catamorphisms. I remind that such an addition as the one
    proposed by N4191, together with the semantics of pack expansion as
    we have them right now, complete an important fold/fmap duo for the
    purposes of an interesting take on functional programming style. So
      yes, having something more than operators there is important.

    

    Regards,

    

    George

    

    

  








-- 



--- 

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 http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.


------=_Part_825_1522406545.1413406167639--

.