220 13972 <5440BE1C.5080900@irrequietus.eu> article Path: news.gmane.org!not-for-mail From: George Makrydakis Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comment on N4191 - Folding expressions (Sutton, Smith) Date: Fri, 17 Oct 2014 09:58:36 +0300 Lines: 542 Approved: news@gmane.org Message-ID: <5440BE1C.5080900@irrequietus.eu> References: <543E7CB4.7020003@gmx.net> <543E8241.7060307@irrequietus.eu> <543EC30A.5030103@gmx.net> <543ED027.10509@irrequietus.eu> <543F5CF3.6010508@gmx.net> <543F98CB.9040803@irrequietus.eu> <54401A9D.5020808@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080709050103020405010001" X-Trace: ger.gmane.org 1413529011 18020 80.91.229.3 (17 Oct 2014 06:56:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2014 06:56:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDFMPCO5SAFRBK73QKRAKGQEIN5B4ZI@isocpp.org Fri Oct 17 08:56:46 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xf1Su-000114-Tg for gclcip-std-proposals@m.gmane.org; Fri, 17 Oct 2014 08:56:45 +0200 Original-Received: by mail-pd0-f197.google.com with SMTP id y10sf1091117pdj.4 for ; Thu, 16 Oct 2014 23:56:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-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:content-type; bh=jSaBK36VnS75Z4cf1N45P6a0BLaXGEMGOYlfolGH+3c=; b=Ebm39eELujlCqvIvIDNVrCJhU7FxjP/MmEQVr0ab6pehLCieowNR3/2KAEh3Y72lCA T2QyAIUMo3ctGq27lL6EbcEv7duo23NsfKR6FiYn0lcldtOGZ7+mw29ycnkNC8GTercP AIyulYBk3BZTU3bseGTMx2kZ6tDiER02yyhRtHDcVYfflx+MI5AR9bHoNmCSHKBlEkrO npIzfC9VUkADZaGZuzi5Cf1mANR+OFiM9WJymBWENYVp6Nq9dH/uJzvShHaejVa47N8W 1KMkql7MD2sydJ+4gwrw2vVcfyQfV5G2AdvbxSDAMBYm2dYnNti8qns/bEBLVxUr6XqX 7OtA== X-Gm-Message-State: ALoCoQlXv4RhfaQXedXJnfRwdhTNU9qI9WXKqO5ltBWKEHh609xK7A5REbjB+SqiCkzjy1JV3JeG X-Received: by 10.66.222.98 with SMTP id ql2mr4559637pac.28.1413529003733; Thu, 16 Oct 2014 23:56:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.143.104 with SMTP id sd8ls800850igb.18.gmail; Thu, 16 Oct 2014 23:56:42 -0700 (PDT) X-Received: by 10.66.237.165 with SMTP id vd5mr6662779pac.34.1413529002849; Thu, 16 Oct 2014 23:56:42 -0700 (PDT) Original-Received: from sender1.zohomail.com (sender1.zohomail.com. [74.201.84.155]) by mx.google.com with ESMTPS id pm1si408961pbb.88.2014.10.16.23.56.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 Oct 2014 23:56:42 -0700 (PDT) Received-SPF: pass (google.com: domain of george@irrequietus.eu designates 74.201.84.155 as permitted sender) client-ip=74.201.84.155; Original-Received: from [192.168.1.8] (athedsl-03861.home.otenet.gr [87.202.15.51]) by mx.zohomail.com with SMTPS id 1413528998736610.725355580236; Thu, 16 Oct 2014 23:56:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 In-Reply-To: <54401A9D.5020808@gmx.net> X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Original-Sender: george@irrequietus.eu X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of george@irrequietus.eu designates 74.201.84.155 as permitted sender) smtp.mail=george@irrequietus.eu 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:13972 Archived-At: This is a multi-part message in MIME format. --------------080709050103020405010001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/16/2014 10:21 PM, Jens Maurer wrote: > On 10/16/2014 12:07 PM, George Makrydakis wrote: >> On 10/16/2014 08:51 AM, Jens Maurer wrote: >>> That's indeed a good follow-on question: In the function case, >>> what's the result for 0-argument lists? >> You already reply yourself in the following paragraph. An empty list sho= uld by definition return the identity (e.g. additive, multiplicative etc) o= f the operation involved. Or in context of the paper, the "neutral" element= .. > That's easy for + and * in particular, but, again, what's the > result for 0-argument lists in the (general) function case? > Or is that supposed to be ill-formed? The authors give an interesting hint as to what happens with the comma=20 operator in their proposal, which gives the return of void(). I would=20 think that this is an excellent suggestion to use for function related=20 folds, because void represents the most fundamental representation of=20 "empty"-ness in C/C++ context. I would prefer having well-formedness for=20 empty lists by having the fold conclude into the same void() by convention. > >>> Not just template overloads, simple overloads do it. Or even no >>> overloads, if you allow implicit conversions. Example: >>> >>> bool f(short, long); >>> >>> (args f ...) will expand to f(f(f(a1, a2), a3), a4) >>> if I understood the syntax right. And that could be made >>> to work even if a2 would have a different type compared to a1, >>> using implicit conversions. >>> >>> What are the rules here? >> We are not disagreeing, see previous paragraph. > I'm sorry, but I'm not trying to make a counter-proposal > of any sort; I'm trying hard to understand your suggestion. > > N4191 doesn't describe any constraints on the element types > of the pack; I'm just asking whether your "function" extension > suggestion has any such constraints. If the answer is "no" > (for consistency with overloaded operators, to say the least), > that's fine and I'm happy. There shouldn't be any constraints in a few words, correct. I am=20 over-analyzing it. > >>>> 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. >>> Why? Implicit conversions happen in C++ all the time. >> See before, It is not about implicit conversions, it is about the fact t= hat folds on heterogeneous lists can have some interesting properties. This= should be better discussed in the setting of general catamorphisms. I do n= ot think that discussing it in this setting it would help the discussion. I= t would confuse people who lack the background (not implying you, I don't k= now you), and my experience with this list shows that most are blissfully u= naware of these things. Implicit conversions are evil here if not properly = managed. > I'm sorry; now I'm really confused. N4191 shows a syntax expansion > of the fold, and, since no further constraints are given, I'd assume > that syntax expansion is then interpreted according to the usual C++ > rules, including overload resolution and implicit conversions. > > And yes, implicit conversions might mean all sorts of trouble, including > possibly picking a different overload for each step in the fold. > > Do you suggest to prohibit differing element types in the pack > (i.e. having a homogenous list only) to avoid such troubles or not? There is no reason to constrain the language-level construct of folds if=20 they ever become part of it. One can use for example material coming=20 from N3878=20 and=20 a successive revision to do the following with functions: template void fun(A,B) {} /* using void on purpose here of course */ template int fun(T, T) { /* implementation here */ } (... fun args) /* the types are the same */ (... fun args) /* the types can be different */ I am using "Suttonian/Ballonian" syntax in a way that is not proposed by=20 them (other than auto{} conventions), but I don't think I would be far=20 off from what they may come up with, should this be a case for folding=20 expressions with functions used with concepts in-situ. This is fairly=20 well contained and predictable. The alternative would be sfinae-ing the=20 function template instantiation using args... expansion within a=20 enable_if like template for such purpose. Pick any likely solution that=20 may appeal. So it shouldn't be a problem. If you are interested in this,=20 talk to them in Urbana and see what they think about it. Perhaps it is=20 already in their plans or you could form a proposal for it since you are=20 better acquainted with the working groups in general. I won't pursue this. > >> It is not my proposal, it is their proposal and I asked why they did not= consider this or if they will consider it. >> >> By definition, you need a binary function in a such fold (I am not sayin= g to change that), > Great. One more question answered. > >> As a library feature, it isn't that this cannot be properly done through= code generation either through template/constexpr trickery etc. If one nee= ds "weird syntax" to go with it as well, there is the preprocessor that can= help out. So, why bother doing it and going through a process that yields = nothing, other than just offering feedback on what is already written in N4= 191? > And maybe it's the right approach to use std::accumulate for (named) func= tions. > > The desire for core language support of the operator case in N4191 comes > from "requires" expressions in concepts where we can't really call other > library functions. Concepts are the issue because they are problematic with such things,=20 but in aiding them to achieve their goals, you are only going to be=20 helping infamous techniques of template meta-programming in becoming=20 more numerous, intense and arcane. One needs to understand that in order for the predicate nature of=20 concepts to work with variadics, the fold is the fundamental construct=20 upon through which they actually work, as per N3701=20 . In=20 page 31 of 56, the authors are effectively performing a fold over an=20 argument list using a binary operator (&&). The example also implies=20 that 'Args' list had been passed through an fmap (structure preserving=20 transformation, "mapping") has been made to a Convertible=20 in each argument. In essence, they are working with functors=20 type-theoretically (distinguishing this from the term we use in C++) and=20 that is what I see when I deal with such work. The interesting thing is that if they go through with these folding=20 expressions, they can also be used for using sfinae manipulations based=20 on folds. I remind that we already have the fmap construct as a language=20 level feature because of the triple-dot pack expansion semantics, so=20 adding a fold expression that can use that, one way or the other, yields=20 interesting effects. For the record, here is the basic construct we=20 already have: template class F, typename... X> void fun(F...) {}; /* F,F,.... */ Dare I say this now: if by C++17 we get folding expressions to combine=20 with the above, with concrete semantics for empty lists, combining them=20 with pack expansion semantics will make it easier for people like me to=20 implement extremely efficient compile-time /monads/=20 over=20 such lists of arguments without even touching concepts. There is=20 bibliography for this already by some authors and the benefit for at=20 least error-reporting during compile-time, but I digress. > >> If I were to work on introducing a construct for folding expressions mys= elf, I would have not taken a path that would be limited to values but also= to types, making sure that the semantics of both fold (see std::accumulate= for example) and fmap (see what std::transform does for example) would be = covered equally in all cases. I however do not think that C++ is suitable t= o such thinking at a language level because some of the people involved in = taking decisions have their own ideas on who is allowed to do what - or per= haps are not all well equipped by their background for these things yet. > My understanding is that there are indeed people in EWG that look at the > entire picture, even though individual proposals are usually just changin= g > one focused aspect of the language. > > In general, when someone asks a question, that's usually a genuine questi= on > to help understand the workings of a proposed feature (often giving a spe= cific > code example), and a short, factual answer is all that is expected. It's > helpful to keep in mind that the people attending meetings are from a div= erse > field of experience and few are experts in the domain being presented. > > I felt that our discussion above wasn't sufficiently to the point: > I have no background in type theory, and all I wanted to know is whether > you'd want to support functions with other than two arguments for the > foldings, and if so, how that might work. The short answer is > "binary functions only, as per the syntax expansion shown in N4191", and > that would have saved quite a few bits in the communication. > , > Jens > I do not doubt your motivation. Sorry if I sounded offensive. In all honesty, I am quite a bit sour from my dealings with the EWG and=20 that leads to needless defensivism. Of course, I do not claim that I am the sole person with such ideas; it=20 is just that in their meeting I was and such ideas were deemed "too=20 complex". Indeed some people are getting some of the picture (with some=20 delay) since they are re-proposing in part what I was trying to say;=20 having entrusted a partially complete work to them was a mistake and I=20 have no care for political correctness. I think I will conclude my lamentful contributions in this standards=20 community for now, since they spawned what they had to spawn. It isn't=20 that I won't be seeing these things in C++ (eventually), even though=20 with different syntax and more limited scope. In a sense, it is=20 flattering for me to witness these things. My first-hand view of this=20 community is complete so there isn't much else to say from either parties. Regards and good luck, George --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --------------080709050103020405010001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 10/16/2014 10:21 PM, Jens Maurer wrote:
On 10/16/2014 12:07 PM, George Makrydakis wrote:

On 10/16/2014 08:51 AM, Jens Maurer wrote:


      

        

          
That's indeed a good follow-on question: In the fu=
nction case,
what's the result for 0-argument lists?


        

        
You already reply yourself in the following paragraph. An empty list should=
 by definition return the identity (e.g. additive, multiplicative etc) of t=
he operation involved. Or in context of the paper, the "neutral" element.


      

      
That's easy for + and * in particular, but, again, what's the
result for 0-argument lists in the (general) function case?
Or is that supposed to be ill-formed?

    

    The authors give an interesting hint as to what happens with the
    comma operator in their proposal, which gives the return of void().
    I would think that this is an excellent suggestion to use for
    function related folds, because void represents the most fundamental
    representation of "empty"-ness in C/C++ context. I would prefer
    having well-formedness for empty lists by having the fold conclude
    into the same void() by convention.

    

      



      

        

          
Not just template overloads, simple overloads do i=
t.  Or even no
overloads, if you allow implicit conversions.   Example:

  bool f(short, long);

  (args f ...) will expand to   f(f(f(a1, a2), a3), a4)
if I understood the syntax right.  And that could be made
to work even if a2 would have a different type compared to a1,
using implicit conversions.

What are the rules here?


        

        
We are not disagreeing, see previous paragraph.


      

      
I'm sorry, but I'm not trying to make a counter-proposal
of any sort; I'm trying hard to understand your suggestion.

N4191 doesn't describe any constraints on the element types
of the pack; I'm just asking whether your "function" extension
suggestion has any such constraints.  If the answer is "no"
(for consistency with overloaded operators, to say the least),
that's fine and I'm happy.

    

    There shouldn't be any constraints in a few words, correct. I am
    over-analyzing it.

    

      



      

        

          

            
 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.


          

          
Why?  Implicit conversions happen in C++ all the t=
ime.


        

        
See before, It is not about implicit conversions, it is about the fact that=
 folds on heterogeneous lists can have some interesting properties. This sh=
ould be better discussed in the setting of general catamorphisms. I do not =
think that discussing it in this setting it would help the discussion. It w=
ould confuse people who lack the background (not implying you, I don't know=
 you), and my experience with this list shows that most are blissfully unaw=
are of these things. Implicit conversions are evil here if not properly man=
aged.


      

      
I'm sorry; now I'm really confused.  N4191 shows a syntax expansion
of the fold, and, since no further constraints are given, I'd assume
that syntax expansion is then interpreted according to the usual C++
rules, including overload resolution and implicit conversions.

And yes, implicit conversions might mean all sorts of trouble, including
possibly picking a different overload for each step in the fold.

Do you suggest to prohibit differing element types in the pack
(i.e. having a homogenous list only) to avoid such troubles or not?

    

    There is no reason to constrain the language-level construct of
    folds if they ever become part of it. One can use for example
    material coming from N3878
    and a successive revision to do the following with functions:

    

    template<typename A, typename B>

    void fun(A,B) {} /* using void on purpose here of course */

    

    template<typename T>

    int fun(T, T) { /* implementation here */ }

    

    (... fun<auto{T},T> args)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* the types are the
    same */

    (... fun<auto{A},auto{B}> args) /* the types can be different
    */

    

    I am using "Suttonian/Ballonian" syntax in a way that is not
    proposed by them (other than auto{} conventions), but I don't think
    I would be far off from what they may come up with, should this be a
    case for folding expressions with functions used with concepts
    in-situ. This is fairly well contained and predictable. The
    alternative would be sfinae-ing the function template instantiation
    using args... expansion within a enable_if like template for such
    purpose. Pick any likely solution that may appeal. So it shouldn't
    be a problem. If you are interested in this, talk to them in Urbana
    and see what they think about it. Perhaps it is already in their
    plans or you could form a proposal for it since you are better
    acquainted with the working groups in general. I won't pursue this.

    

    

      



      

        
It is not my proposal, it is their proposal and I as=
ked why they did not consider this or if they will consider it.

By definition, you need a binary function in a such fold (I am not saying t=
o change that),


      

      
Great.  One more question answered.



      

        
As a library feature, it isn't that this cannot be p=
roperly done through code generation either through template/constexpr tric=
kery etc. If one needs "weird syntax" to go with it as well, there is the p=
reprocessor that can help out. So, why bother doing it and going through a =
process that yields nothing, other than just offering feedback on what is a=
lready written in N4191?


      

      
And maybe it's the right approach to use std::accumulate for (named) functi=
ons.

The desire for core language support of the operator case in N4191 comes
from "requires" expressions in concepts where we can't really call other
library functions.

    

    

    Concepts are the issue because they are problematic with such
    things, but in aiding them to achieve their goals, you are only
    going to be helping infamous techniques of template meta-programming
    in becoming more numerous, intense and arcane.

    

    One needs to understand that in order for the predicate nature of
    concepts to work with variadics, the fold is the fundamental
    construct upon through which they actually work, as per N3701.
    In page 31 of 56, the authors are effectively performing a fold over
    an argument list using a binary operator (&&). The example
    also implies that 'Args' list had been passed through an fmap
    (structure preserving transformation, "mapping") has been made to a
    Convertible<ArgN,size_t> in each argument. In essence, they
    are working with functors type-theoretically (distinguishing this
    from the term we use in C++) and that is what I see when I deal with
    such work.

    

    The interesting thing is that if they go through with these folding
    expressions, they can also be used for using sfinae manipulations
    based on folds. I remind that we already have the fmap construct as
    a language level feature because of the triple-dot pack expansion
    semantics, so adding a fold expression that can use that, one way or
    the other, yields interesting effects. For the record, here is the
    basic construct we already have:

    

    template<template<typename> class F, typename... X>

    void fun(F<X>...) {}; /* F<X0>,F<X1>,.... */

    

    Dare I say this now: if by C++17 we get folding expressions to
    combine with the above, with concrete semantics for empty lists,
    combining them with pack expansion semantics will make it easier for
    people like me to implement extremely efficient compile-time monads
    over such lists of arguments without even touching concepts.
    There is bibliography for this already by some authors and the
    benefit for at least error-reporting during compile-time, but I
    digress.

    

    

      



      

        
If I were to work on introducing a construct for fol=
ding expressions myself, I would have not taken a path that would be limite=
d to values but also to types, making sure that the semantics of both fold =
(see std::accumulate for example) and fmap (see what std::transform does fo=
r example) would be covered equally in all cases. I however do not think th=
at C++ is suitable to such thinking at a language level because some of the=
 people involved in taking decisions have their own ideas on who is allowed=
 to do what - or perhaps are not all well equipped by their background for =
these things yet.


      

      
My understanding is that there are indeed people in EWG that look at the
entire picture, even though individual proposals are usually just changing
one focused aspect of the language.

In general, when someone asks a question, that's usually a genuine question
to help understand the workings of a proposed feature (often giving a speci=
fic
code example), and a short, factual answer is all that is expected.  It's
helpful to keep in mind that the people attending meetings are from a diver=
se
field of experience and few are experts in the domain being presented.

I felt that our discussion above wasn't sufficiently to the point:
I have no background in type theory, and all I wanted to know is whether
you'd want to support functions with other than two arguments for the
foldings, and if so, how that might work.  The short answer is
"binary functions only, as per the syntax expansion shown in N4191", and
that would have saved quite a few bits in the communication.
,
Jens



    

    I do not doubt your motivation. Sorry if I sounded offensive.

    

    In all honesty, I am quite a bit sour from my dealings with the EWG
    and that leads to needless defensivism. 

    

    Of course, I do not claim that I am the sole person with such ideas;
    it is just that in their meeting I was and such ideas were deemed
    "too complex". Indeed some people are getting some of the picture
    (with some delay) since they are re-proposing in part what I was
    trying to say; having entrusted a partially complete work to them
    was a mistake and I have no care for political correctness.

    

    I think I will conclude my lamentful contributions in this standards
    community for now, since they spawned what they had to spawn. It
    isn't that I won't be seeing these things in C++ (eventually), even
    though with different syntax and more limited scope. In a sense, it
    is flattering for me to witness these things. My first-hand view of
    this community is complete so there isn't much else to say from
    either parties.

    

    Regards and good luck,

    

    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>.


--------------080709050103020405010001--


.