------=_Part_297_782585656.1413373516079
Content-Type: text/plain; charset=UTF-8

Two observations on N4191:

First, given that the paper proposes making catamophisms (left and right
folds) as a primary language construct,
is there a reason as to why this should be limited to just values and not
types as well? Instead of an operator, a
template template parameter could be used as is the case for the following
examples of valid C++11 code for
providing the "folded" instantiation in this case:

#include <cstdio>

template< template<typename...> class F
             , typename A, typename B, typename C, typename D>
void fun (F<A,F<B,F<C,D>>>)
{ printf("folding in one way...\n"); }

template< template<typename...> class F
             , typename A, typename B, typename C, typename D>
void fun (F<F<F<A,B>,C>,D>)
{ printf("folding in another way...\n"); }

template<typename A, typename B>
struct funny {};

int main() {
    fun(funny<int,funny<int,funny<int,long>>>());
    fun(funny<funny<funny<int,int>,int>,long>());
    return {};
}

With the intention of expanding this to packs of course, manipulating the
tripple-dot syntax. Could N4191 address
this as well in a future iteration?

Second, why should the folding expressions be limited to operators using
(... + args) and not functions as well,
using (... f args) as well with f being a function identifier, or some sort
of other syntax including that f function
can be used with, inspired for example from N4165 / N4174 (uniform function
call syntax)?

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_297_782585656.1413373516079
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Two observations on N4191:<br><br>First, given that the pa=
per proposes making catamophisms (left and right folds) as a primary langua=
ge construct,<br>is there a reason as to why this should be limited to just=
 values and not types as well? Instead of an operator, a<br>template templa=
te parameter could be used as is the case for the following examples of val=
id C++11 code for<br>providing the "folded" instantiation in this case:<br>=
<br>#include &lt;cstdio&gt;<br><br>template&lt; template&lt;typename...&gt;=
 class F<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; , typename A, typename B, typename C, typename D&gt;<br>void fun =
(F&lt;A,F&lt;B,F&lt;C,D&gt;&gt;&gt;)<br>{ printf("folding in one way...\n")=
; }<br><br>template&lt; template&lt;typename...&gt; class F<br>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; , typename A, =
typename B, typename C, typename D&gt;<br>void fun (F&lt;F&lt;F&lt;A,B&gt;,=
C&gt;,D&gt;)<br>{ printf("folding in another way...\n"); }<br><br>template&=
lt;typename A, typename B&gt;<br>struct funny {};<br><br>int main() {<br>&n=
bsp;&nbsp;&nbsp; fun(funny&lt;int,funny&lt;int,funny&lt;int,long&gt;&gt;&gt=
;());<br>&nbsp;&nbsp;&nbsp; fun(funny&lt;funny&lt;funny&lt;int,int&gt;,int&=
gt;,long&gt;());<br>&nbsp;&nbsp;&nbsp; return {};<br>}<br><br>With the inte=
ntion of expanding this to packs of course, manipulating the tripple-dot sy=
ntax. Could N4191 address<br>this as well in a future iteration?<br><br>Sec=
ond, why should the folding expressions be limited to operators using (... =
+ args) and not functions as well,<br>using (... f args) as well with f bei=
ng a function identifier, or some sort of other syntax including that f fun=
ction<br>can be used with, inspired for example from N4165 / N4174 (uniform=
 function call syntax)?<br><br>Regards,<br><br>George<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_297_782585656.1413373516079--

.

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.

Jens


On 10/15/2014 01:45 PM, George Makrydakis wrote:
> Two observations on N4191:
>
> First, given that the paper proposes making catamophisms (left and right folds) as a primary language construct,
> is there a reason as to why this should be limited to just values and not types as well? Instead of an operator, a
> template template parameter could be used as is the case for the following examples of valid C++11 code for
> providing the "folded" instantiation in this case:
>
> #include <cstdio>
>
> template< template<typename...> class F
>              , typename A, typename B, typename C, typename D>
> void fun (F<A,F<B,F<C,D>>>)
> { printf("folding in one way...\n"); }
>
> template< template<typename...> class F
>              , typename A, typename B, typename C, typename D>
> void fun (F<F<F<A,B>,C>,D>)
> { printf("folding in another way...\n"); }
>
> template<typename A, typename B>
> struct funny {};
>
> int main() {
>     fun(funny<int,funny<int,funny<int,long>>>());
>     fun(funny<funny<funny<int,int>,int>,long>());
>     return {};
> }
>
> With the intention of expanding this to packs of course, manipulating the tripple-dot syntax. Could N4191 address
> this as well in a future iteration?
>
> Second, why should the folding expressions be limited to operators using (... + args) and not functions as well,
> using (... f args) as well with f being a function identifier, or some sort of other syntax including that f function
> can be used with, inspired for example from N4165 / N4174 (uniform function call syntax)?
>
> 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 <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

.

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.
>
> Jens
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?). 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.

Regards,

George
>
> On 10/15/2014 01:45 PM, George Makrydakis wrote:
[...snip...]
> Second, why should the folding expressions be limited to operators using (... + args) and not functions as well,
> using (... f args) as well with f being a function identifier, or some sort of other syntax including that f function
> can be used with, inspired for example from N4165 / N4174 (uniform function call syntax)?
>
> 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/.

.

On 10/15/2014 05: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.
>>
>> Jens
> 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?). 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)

Typing mistake, I left the second argument out due to haste:

(... [](auto x, auto y) { /* 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.
>
> Regards,
>
> George
>>
>> On 10/15/2014 01:45 PM, George Makrydakis wrote:
> [...snip...]
>> Second, why should the folding expressions be limited to operators
>> using (... + args) and not functions as well,
>> using (... f args) as well with f being a function identifier, or
>> some sort of other syntax including that f function
>> can be used with, inspired for example from N4165 / N4174 (uniform
>> function call syntax)?
>>
>> 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/.

.

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.

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

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.

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.

Jens

--

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

.

This is a multi-part message in MIME format.
--------------090909050109070909080309
Content-Type: text/plain; charset=UTF-8; format=flowed


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

--------------090909050109070909080309
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/15/2014 09:55 PM, Jens Maurer
      wrote:<br>
    </div>
    <blockquote cite="mid:543EC30A.5030103@gmx.net" type="cite">
      <pre wrap="">On 10/15/2014 04:18 PM, George Makrydakis wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
On 10/15/2014 04:55 PM, Jens Maurer wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">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.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">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?).
</pre>
      </blockquote>
      <pre wrap="">
Probably not.  Ask the author to be sure.  Otherwise, feel free to
write a paper yourself.</pre>
    </blockquote>
    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 :)
    <blockquote cite="mid:543EC30A.5030103@gmx.net" type="cite">
      <blockquote type="cite">
        <pre wrap=""> 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.
</pre>
      </blockquote>
      <pre wrap="">
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?</pre>
    </blockquote>
    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:<br>
    <br>
    <a
href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ</a>:<br>
    <br>
    (... [](auto x, auto y) { /* implementation here */ } args)<br>
    <br>
    The <i>correct comment</i> 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.<br>
    <br>
    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 &lt;algorithm&gt; 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.<br>
    <br>
    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.<br>
    <blockquote cite="mid:543EC30A.5030103@gmx.net" type="cite">
      <pre wrap="">

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.</pre>
    </blockquote>
    I think you should think more about it. In essence, they are
    providing a new kind of <i>"binary operator expression"</i> 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.<br>
    <br>
    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 (<a
      href="http://en.wikipedia.org/wiki/S-expression">http://en.wikipedia.org/wiki/S-expression</a>).<br>
    <blockquote cite="mid:543EC30A.5030103@gmx.net" type="cite">
      <pre wrap="">

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.</pre>
    </blockquote>
    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 <i>the actual constraint</i> is.<br>
    <br>
    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. <i>So
      yes, having something more than operators there is important.</i><br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------090909050109070909080309--


.

------=_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 <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 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

<div dir=3D"ltr">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).<div>A=
re there any?&nbsp;<br><br>On Wednesday, October 15, 2014 11:51:20 PM UTC+4=
, George Makrydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div>On 10/15/2014 09:55 PM, Jens Maurer
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>On 10/15/2014 04:18 PM, George Makrydakis wrote:
</pre>
      <blockquote type=3D"cite">
        <pre>On 10/15/2014 04:55 PM, Jens Maurer wrote:
</pre>
        <blockquote type=3D"cite">
          <pre>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.
</pre>
        </blockquote>
      </blockquote>
      <pre></pre>
      <blockquote type=3D"cite">
        <pre>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?).
</pre>
      </blockquote>
      <pre>Probably not.  Ask the author to be sure.  Otherwise, feel free =
to
write a paper yourself.</pre>
    </blockquote>
    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 :)
    <blockquote type=3D"cite">
      <blockquote type=3D"cite">
        <pre> 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.
</pre>
      </blockquote>
      <pre>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?</pre>
    </blockquote>
    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:<br>
    <br>
    <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/O=
18-SNExUdw/wxf5VleV6uEJ" target=3D"_blank" onmousedown=3D"this.href=3D'http=
s://groups.google.com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV=
6uEJ';return true;" onclick=3D"this.href=3D'https://groups.google.com/a/iso=
cpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ';return true;">https:/=
/groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals/O18-SNExUdw/<=
wbr>wxf5VleV6uEJ</a>:<br>
    <br>
    (... [](auto x, auto y) { /* implementation here */ } args)<br>
    <br>
    The <i>correct comment</i> 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.<br>
    <br>
    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 &lt;algorithm&gt; 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.<br>
    <br>
    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.<br>
    <blockquote type=3D"cite">
      <pre>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.</pre>
    </blockquote>
    I think you should think more about it. In essence, they are
    providing a new kind of <i>"binary operator expression"</i> 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.<br>
    <br>
    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 (<a href=3D"http://en.wikipedia.org/wiki=
/S-expression" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FS-expression\46sa\75=
D\46sntz\0751\46usg\75AFQjCNHWPAK_fnRRLzp1ZkAtxKBIVaRL4Q';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fen.wikipedi=
a.org%2Fwiki%2FS-expression\46sa\75D\46sntz\0751\46usg\75AFQjCNHWPAK_fnRRLz=
p1ZkAtxKBIVaRL4Q';return true;">http://en.wikipedia.org/wiki/<wbr>S-express=
ion</a>).<br>
    <blockquote type=3D"cite">
      <pre>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.</pre>
    </blockquote>
    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 <i>the actual constraint</i> is.<br>
    <br>
    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. <i>So
      yes, having something more than operators there is important.</i><br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
    <br>
  </div>

</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

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

.

On 10/15/2014 10:49 PM, Vadim Petrochenkov wrote:
> 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?

Binary && and || do contextual-bool conversions on their arguments
(possibly invoking an explicit operator bool), whereas a function
call doesn't.

The implicit conversion rules for arguments of + or *
("usual arithmetic conversions") make it hard to provide an
equivalent overload set containing functions, without running
into all sorts of ambiguity issues.

Jens


--

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

.

On 10/15/2014 09:51 PM, George Makrydakis wrote:
>
> On 10/15/2014 09:55 PM, Jens Maurer wrote:
>> On 10/15/2014 04:18 PM, George Makrydakis wrote:
>>> 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 :)

I'm not sure who "they" are in the last sentence.

You asked whether the authors of N4191 are going to write a separate
paper discussing folding on template-arguments.  I said "probably not,
ask them to be sure".   So, if you want to see this extension happen,
yet you refrain from asking the paper authors for a change
directly, all that is left is writing the paper yourself or asking
someone else to do it.  Otherwise, it won't happen.

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

>   Such catamorphisms
> over lists obviously require a binary function, as is the way through

I'm not sure about "obvious".  I'm mostly hanging around in the core
language working group, and there, we like to have all rules of the
C++ language spelled out explicitly.  If you want to say that your
proposal is limited to functions having two parameters, you should
say so.   Otherwise, I'm going to ask.  The only hint you gave at
the actual function signature to be supported was the lambda, which
didn't match my expectations, so I was confused.

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

I saw this after I sent my e-mail.  Ok.

> The /correct comment/ in your defense on this would be to ascertain

I don't think I need a "defense".  All I'm trying to do with my
questions is to clarify what the proposal actually is, so that
I can form a firmer opinion.

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

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

>   The authors deal with this in their own paper (in a way),

They expressly prescribe the neutral element as the result for
0-argument lists, for each binary operation supported.  Is there
something wrong with that?

> while it is obvious that there are far too many ways to ascertain
> that.

I'm sorry, I don't understand this part of the sentence.

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

So, is there a constraint that all elements of the pack be of the
same type?  That's not a constraint for the operators (conversions
are allowed there).  In any case, this would be a further difference
for the function case that needs to be spelled out.

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

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?

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

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

I'm not sure what you want to say here.  Again, I'm asking about
the features of your proposal, and if you wish to require that
"f" (the function subject to the folding) is a binary function,
you should clearly say so, and not assume someone will deduce
it from the surroundings.

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

I'm not talking about a learning issue, I was asking about the
specification itself.  To me, there's no question that the
concept of a binary function is well-established.

>> 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 was talking about parsing ambiguities.  I'm still feeling uneasy
here.  Is the "most vexing parse" getting more difficult?

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

Why?  If you submit the paper now, it certainly has a chance
to get into C++17.

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

Then you should write an e-mail to the authors, maybe they're
sympathetic to your wishes and extend their paper.

Jens

--

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

.

This is a multi-part message in MIME format.
--------------060207020700050307000706
Content-Type: text/plain; charset=UTF-8; format=flowed


On 10/16/2014 08:51 AM, Jens Maurer wrote:
> On 10/15/2014 09:51 PM, George Makrydakis wrote:
>> On 10/15/2014 09:55 PM, Jens Maurer wrote:
>>> On 10/15/2014 04:18 PM, George Makrydakis wrote:
>>>> 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 :)
> I'm not sure who "they" are in the last sentence.
>
> You asked whether the authors of N4191 are going to write a separate
> paper discussing folding on template-arguments.  I said "probably not,
> ask them to be sure".   So, if you want to see this extension happen,
> yet you refrain from asking the paper authors for a change
> directly, all that is left is writing the paper yourself or asking
> someone else to do it.  Otherwise, it won't happen.

These people already working on it, I am only only providing feedback
they do read. I am not going to be writing a paper on this because it is
not worth it. It is just an omission on their behalf and perhaps their
plan is to introduce this at some latter point. They have more leverage
than an outsider to those working groups so I prefer not being the one
doing the enlightenment.

>
>>> 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?
>>    Such catamorphisms
>> over lists obviously require a binary function, as is the way through
> I'm not sure about "obvious".  I'm mostly hanging around in the core
> language working group, and there, we like to have all rules of the
> C++ language spelled out explicitly.  If you want to say that your
> proposal is limited to functions having two parameters, you should
> say so.   Otherwise, I'm going to ask.  The only hint you gave at
> the actual function signature to be supported was the lambda, which
> didn't match my expectations, so I was confused.
The very definition of a fold requires a binary function that and I
believe that this is not confusing to anybody in the field:

http://en.wikipedia.org/wiki/Fold_%28higher-order_function%29

Also, let's see an example of where the standard itself implies that a
binary operation (meaning 2-arity) is passed, this is quite old actually
and existing the standard library:

(taken from http://en.cppreference.com/w/cpp/algorithm/transform):

template< class InputIt1, class InputIt2, class OutputIt, class
BinaryOperation >
OutputIt transform( InputIt1 first1, InputIt1 last1, InputIt2 first2,
                     OutputIt d_first, BinaryOperation binary_op );

Also, take note that std::accumulate itself, which is actually doing one
kind of folding has the following function template overload, again in
the standard library:

(taken from http://en.cppreference.com/w/cpp/algorithm/accumulate):

template< class InputIt, class T, class BinaryOperation >
T accumulate( InputIt first, InputIt last, T init, BinaryOperation op );

I understand that in C++, one can simply take any term (see functor in
the context of category theory and functor in the context of C++) and
change its meaning. But the meaning of a fold, is universal and all
discussions on this follow a series of notions taken for granted.

>
>> 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)
> I saw this after I sent my e-mail.  Ok.

Not a problem.

>
>> The /correct comment/ in your defense on this would be to ascertain
> I don't think I need a "defense".  All I'm trying to do with my
> questions is to clarify what the proposal actually is, so that
> I can form a firmer opinion.

Sure, the term "defense" is for the argument, I grant that it sounds too
aggressive and can be taken in the wrong way. Substitute with "in
defense of the argument" and we are in context.

>
>> 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.
> 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
should by definition return the identity (e.g. additive, multiplicative
etc) of the operation involved. Or in context of the paper, the
"neutral" element.

>
>>    The authors deal with this in their own paper (in a way),
> They expressly prescribe the neutral element as the result for
> 0-argument lists, for each binary operation supported.  Is there
> something wrong with that?

There is nothing wrong with that because that is how it is done in
mathematics. The terms multiplicative and additive identity are globally
acceptable as well for example when you multiply (*) or add (+) and so
on for other operations.

>
>> while it is obvious that there are far too many ways to ascertain
>> that.
> I'm sorry, I don't understand this part of the sentence.

Concepts, sfinae, etc depending on the pack size to be processed, proper
use of the "neutral" element, which actually refers to the notion of an
identity for said operator and so on. I will not write an entire library
to prove it. Just think about concepts and that is one way to ascertain
that the semantics have a certain coherence. It is not by chance that
one of the authors is involved in concepts ts anyway.

>
>>   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,
> So, is there a constraint that all elements of the pack be of the
> same type?  That's not a constraint for the operators (conversions
> are allowed there).  In any case, this would be a further difference
> for the function case that needs to be spelled out.

If you use function template overloads or even plain non-template
functions restricting by type in any combination, you are doing a fold
in a heterogeneous list (made up of arguments of different types).

Folds on homogeneous lists (made up of arguments of the same type, to
clarify the term) as the one they propose in their "folding expressions"
already imply that the type is the same. It is not a further difference
given that even cases of binary operators that are overloadable in C++
can have a variety of signatures:

http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

Aren't operators just 2-ary functions in the end given that a lot of
conversions take place there when desired? You also bring an example
later on for the function case, let's see it.

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

The syntax expansion is correct, that is the same expansion implied by
the authors (that is the universal way we do a left fold actually, so
they are not changing that). In that case, you will be having a "bool"
recursively passed through implicit conversion to f at each step of the way.

Again, it is not that you do not have operator+ overloads that accept
different types and return a different type as the link above shows, but
you have to respect the fact that the result of the operation is not a
simple "fold" in the sense implied by the authors. You are working on a
heterogeneous list with implicit conversions between calculations. In a
list made up of multiple types, just like a case where packs are
involved, you would be changing the function that is applied through
overload resolution each time. You would have to have some sort of type
deduction to occur to allow the fold or say that it cannot happen. It
isn't that this is not the same problem operator-only solutions won't
face (given that they are overloadable in all parts of their signature).

>
>>   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
that folds on heterogeneous lists can have some interesting properties.
This should 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 would 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 unaware of these things. Implicit conversions
are evil here if not properly managed.

>
>> 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.
> I'm not sure what you want to say here.  Again, I'm asking about
> the features of your proposal, and if you wish to require that
> "f" (the function subject to the folding) is a binary function,
> you should clearly say so, and not assume someone will deduce
> it from the surroundings.

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
saying to change that), but that does not mean that you cannot use an
n-ary where you can default some of the arguments through /partial
application/ (the notion comes from functional programming). It is
especially easy to do in C++11 with std::bind or even a lambda
encapsulating the n-ary function some of whose arguments are "defaulted"
within the body body of a lambda:
--- code
#include <algorithm>
#include <cstdio>
#include <functional>
// C++11 code
using namespace std::placeholders;

int f(int x, int y, int z, int w)
{ return x + y + z + w; }

int main() {
     std::vector<int> v{1,2,3,4,5,6,7,8,9};

     printf("%d\n", std::accumulate( v.begin()
                                   , v.end()
                                   , 0
                                   , std::bind(f,_1,_2,100,200))); // here

     printf("%d\n", std::accumulate( v.begin()
                                   , v.end()
                                   , 0
                                   , [](int x, int y){ return
f(x*y,1,2,3);})); // here
     return {};
}
--- code

I think that it should be clear right now (std::accumulate is doing the
folding here as is widely known).

>
>> 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.
> I'm not talking about a learning issue, I was asking about the
> specification itself.  To me, there's no question that the
> concept of a binary function is well-established.

We have been over this quite a few times. We are always talking about
binary functions, just like the operators are binary. However, any kind
of n-ary function that can be purposefully transformed into a 2-ary
through one of the ways we can do partial application. This is equally
fine since we can provide defaulted arguments, provided that such
application is being done of course in the correct context. The example
given before is clear. I am glad that the notion of function arity is
clear to you, as should be the notion of partial application and
currying. I tried to avoid using these terms (since some C++ programmers
insist on them being just "taxonomy" of no practical use) but no reason
to continue to do so :)

>
>>> 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 was talking about parsing ambiguities.  I'm still feeling uneasy
> here.  Is the "most vexing parse" getting more difficult?

I can very much relate to this because their chosen syntax is uneasy,
but not exactly ambiguous the way they are tackling it. However, it is
their proposal, not mine, you should address them on that when it comes
to the core language group from evolution :). The way they play with the
parentheses and the triple-dot as tokens there is interesting enough.
Not going to present an alternative, it would mean writing a different
paper and I do not wish to do so.

>
>> 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,
> Why?  If you submit the paper now, it certainly has a chance
> to get into C++17.

It has to do with this being worthy of the time for doing something
separate as well as being compatible with whatever agenda there is on
the matter. I am of those people whose experience with the EWG has
disillusioned him about whatever integrity certain procedures have. So I
really do not see the point and let's do not get off topic now, you can
search the mailing lists for this. You have to be part of a lobby in the
end with some people and I see no reason to invest in building that. It
is not that important. I gain zero out of this since it neither enhances
my knowledge, nor does it give me additional credit I do not already
have. I just happen to like the language despite of its woeful design
aspects.

As a library feature, it isn't that this cannot be properly done through
code generation either through template/constexpr trickery etc. If one
needs "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 N4191?

>
>>    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.
> Then you should write an e-mail to the authors, maybe they're
> sympathetic to your wishes and extend their paper.

Again, unlikely to happen for both parts involved in such a process
given that I am doubtful of the process that is to be followed in its
quality and mutual respect. Our discussion was enjoyable indeed. I
prefer the feedback given on this mailing list.

If I were to work on introducing a construct for folding expressions
myself, 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 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.

Nothing that metaprogramming can't cover for those of us who may wish
these things today, despite we don't have them as language features. Or
perhaps a better language than C++, given that true professionals have
to be polyglots. So really, why abuse myself in any other way other than
giving feedback :) It the feedback is good, at some point it will be
used, whether short-term or long-term. It is not that important.

What is important is being honest.

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

--------------060207020700050307000706
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">On 10/16/2014 08:51 AM, Jens Maurer
      wrote:<br>
    </div>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">On 10/15/2014 09:51 PM, George Makrydakis wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">
On 10/15/2014 09:55 PM, Jens Maurer wrote:
</pre>
        <blockquote type=3D"cite">
          <pre wrap=3D"">On 10/15/2014 04:18 PM, George Makrydakis wrote:
</pre>
          <blockquote type=3D"cite">
            <pre wrap=3D"">separate paper (are they going to write it?).
</pre>
          </blockquote>
          <pre wrap=3D"">Probably not.  Ask the author to be sure.  Otherwi=
se, feel free to
write a paper yourself.
</pre>
        </blockquote>
        <pre wrap=3D"">Unlikely to happen not because I am not equipped to =
do it but because it would serve no purpose doing it since there are workin=
g on it. I am not new anymore to how they actually work :)
</pre>
      </blockquote>
      <pre wrap=3D"">
I'm not sure who "they" are in the last sentence.

You asked whether the authors of N4191 are going to write a separate
paper discussing folding on template-arguments.  I said "probably not,
ask them to be sure".   So, if you want to see this extension happen,
yet you refrain from asking the paper authors for a change
directly, all that is left is writing the paper yourself or asking
someone else to do it.  Otherwise, it won't happen.</pre>
    </blockquote>
    <br>
    These people already working on it, I am only only providing
    feedback they do read. I am not going to be writing a paper on this
    because it is not worth it. It is just an omission on their behalf
    and perhaps their plan is to introduce this at some latter point.
    They have more leverage than an outsider to those working groups so
    I prefer not being the one doing the enlightenment.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">Well, for one, the operators in N4191 are all bina=
ry, 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?
</pre>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">  Such catamorphisms
over lists obviously require a binary function, as is the way through
</pre>
      </blockquote>
      <pre wrap=3D"">
I'm not sure about "obvious".  I'm mostly hanging around in the core
language working group, and there, we like to have all rules of the
C++ language spelled out explicitly.  If you want to say that your
proposal is limited to functions having two parameters, you should
say so.   Otherwise, I'm going to ask.  The only hint you gave at
the actual function signature to be supported was the lambda, which
didn't match my expectations, so I was confused.</pre>
    </blockquote>
    The very definition of a fold requires a binary function that and I
    believe that this is not confusing to anybody in the field:<br>
    <br>
    <a
      href=3D"http://en.wikipedia.org/wiki/Fold_%28higher-order_function%29=
">http://en.wikipedia.org/wiki/Fold_%28higher-order_function%29</a><br>
    <br>
    Also, let's see an example of where the standard itself implies that
    a binary operation (meaning 2-arity) is passed, this is quite old
    actually and existing the standard library:<br>
    <br>
    (taken from <a
      href=3D"http://en.cppreference.com/w/cpp/algorithm/transform">http://=
en.cppreference.com/w/cpp/algorithm/transform</a>):<br>
    <br>
    template&lt; class InputIt1, class InputIt2, class OutputIt, class
    BinaryOperation &gt;<br>
    OutputIt transform( InputIt1 first1, InputIt1 last1, InputIt2
    first2,<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OutputIt d_first, BinaryOpera=
tion binary_op );<br>
    <br>
    Also, take note that std::accumulate itself, which is actually doing
    one kind of folding has the following function template overload,
    again in the standard library:<br>
    <br>
    (taken from <a
      href=3D"http://en.cppreference.com/w/cpp/algorithm/accumulate">http:/=
/en.cppreference.com/w/cpp/algorithm/accumulate</a>):<br>
    <br>
    template&lt; class InputIt, class T, class BinaryOperation &gt;<br>
    T accumulate( InputIt first, InputIt last, T init, BinaryOperation
    op );<br>
    <br>
    I understand that in C++, one can simply take any term (see functor
    in the context of category theory and functor in the context of C++)
    and change its meaning. But the meaning of a fold, is universal and
    all discussions on this follow a series of notions taken for
    granted.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">which we define left and right folds in languages ha=
ving 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:

<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google.com/a/isoc=
pp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ">https://groups.google.=
com/a/isocpp.org/d/msg/std-proposals/O18-SNExUdw/wxf5VleV6uEJ</a>:

(... [](auto x, auto y) { /* implementation here */ } args)
</pre>
      </blockquote>
      <pre wrap=3D"">
I saw this after I sent my e-mail.  Ok.</pre>
    </blockquote>
    <br>
    Not a problem.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">The /correct comment/ in your defense on this would =
be to ascertain
</pre>
      </blockquote>
      <pre wrap=3D"">
I don't think I need a "defense".  All I'm trying to do with my
questions is to clarify what the proposal actually is, so that
I can form a firmer opinion.</pre>
    </blockquote>
    <br>
    Sure, the term "defense" is for the argument, I grant that it sounds
    too aggressive and can be taken in the wrong way. Substitute with
    "in defense of the argument" and we are in context.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">that 'args' has a sufficient number of arguments ins=
ide for the fold
to occur, without bailing out on the last call, not just function
arity.
</pre>
      </blockquote>
      <pre wrap=3D"">
That's indeed a good follow-on question: In the function case,
what's the result for 0-argument lists?</pre>
    </blockquote>
    <br>
    You already reply yourself in the following paragraph. An empty list
    should by definition return the identity (e.g. additive,
    multiplicative etc) of the operation involved. Or in context of the
    paper, the "neutral" element.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">  The authors deal with this in their own paper (in =
a way),
</pre>
      </blockquote>
      <pre wrap=3D"">
They expressly prescribe the neutral element as the result for
0-argument lists, for each binary operation supported.  Is there
something wrong with that?</pre>
    </blockquote>
    <br>
    There is nothing wrong with that because that is how it is done in
    mathematics. The terms multiplicative and additive identity are
    globally acceptable as well for example when you multiply (*) or add
    (+) and so on for other operations.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">while it is obvious that there are far too many ways=
 to ascertain
that.
</pre>
      </blockquote>
      <pre wrap=3D"">
I'm sorry, I don't understand this part of the sentence.</pre>
    </blockquote>
    <br>
    Concepts, sfinae, etc depending on the pack size to be processed,
    proper use of the "neutral" element, which actually refers to the
    notion of an identity for said operator and so on. I will not write
    an entire library to prove it. Just think about concepts and that is
    one way to ascertain that the semantics have a certain coherence. It
    is not by chance that one of the authors is involved in concepts ts
    anyway.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D""> Also, given that there is a single function identif=
ier to be
used there, the type signature is predictable in case of arguments of
the same type,
</pre>
      </blockquote>
      <pre wrap=3D"">
So, is there a constraint that all elements of the pack be of the
same type?  That's not a constraint for the operators (conversions
are allowed there).  In any case, this would be a further difference
for the function case that needs to be spelled out.</pre>
    </blockquote>
    <br>
    If you use function template overloads or even plain non-template
    functions restricting by type in any combination, you are doing a
    fold in a heterogeneous list (made up of arguments of different
    types).<br>
    <br>
    Folds on homogeneous lists (made up of arguments of the same type,
    to clarify the term) as the one they propose in their "folding
    expressions" already imply that the type is the same. It is not a
    further difference given that even cases of binary operators that
    are overloadable in C++ can have a variety of signatures:<br>
    <br>
    <a href=3D"http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B">htt=
p://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B</a><br>
    <br>
    Aren't operators just 2-ary functions in the end given that a lot of
    conversions take place there when desired? You also bring an example
    later on for the function case, let's see it.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">  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).
</pre>
      </blockquote>
      <pre wrap=3D"">
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?</pre>
    </blockquote>
    <br>
    We are not disagreeing, see previous paragraph.<br>
    <br>
    The syntax expansion is correct, that is the same expansion implied
    by the authors (that is the universal way we do a left fold
    actually, so they are not changing that). In that case, you will be
    having a "bool" recursively passed through implicit conversion to f
    at each step of the way.<br>
    <br>
    Again, it is not that you do not have operator+ overloads that
    accept different types and return a different type as the link above
    shows, but you have to respect the fact that the result of the
    operation is not a simple "fold" in the sense implied by the
    authors. You are working on a heterogeneous list with implicit
    conversions between calculations. In a list made up of multiple
    types, just like a case where packs are involved, you would be
    changing the function that is applied through overload resolution
    each time. You would have to have some sort of type deduction to
    occur to allow the fold or say that it cannot happen. It isn't that
    this is not the same problem operator-only solutions won't face
    (given that they are overloadable in all parts of their signature).<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D""> 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.
</pre>
      </blockquote>
      <pre wrap=3D"">
Why?  Implicit conversions happen in C++ all the time.</pre>
    </blockquote>
    <br>
    See before, It is not about implicit conversions, it is about the
    fact that folds on heterogeneous lists can have some interesting
    properties. This should 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 would 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 unaware of
    these things. Implicit conversions are evil here if not properly
    managed.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">
=20
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">As for n-ary functions over 2-nary ones as is the ca=
se 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
&lt;algorithm&gt; 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.
</pre>
      </blockquote>
      <pre wrap=3D"">
I'm not sure what you want to say here.  Again, I'm asking about
the features of your proposal, and if you wish to require that
"f" (the function subject to the folding) is a binary function,
you should clearly say so, and not assume someone will deduce
it from the surroundings.</pre>
    </blockquote>
    <br>
    It is not my proposal, it is their proposal and I asked why they did
    not consider this or if they will consider it.<br>
    <br>
    By definition, you need a binary function in a such fold (I am not
    saying to change that), but that does not mean that you cannot use
    an n-ary where you can default some of the arguments through <i>partial
      application</i> (the notion comes from functional programming). It
    is especially easy to do in C++11 with std::bind or even a lambda
    encapsulating the n-ary function some of whose arguments are
    "defaulted" within the body body of a lambda:<br>
    --- code<br>
    #include &lt;algorithm&gt;<br>
    #include &lt;cstdio&gt;<br>
    #include &lt;functional&gt;<br>
    // C++11 code<br>
    using namespace std::placeholders;<br>
    <br>
    int f(int x, int y, int z, int w)<br>
    { return x + y + z + w; }<br>
    <br>
    int main() {<br>
    =C2=A0=C2=A0=C2=A0 std::vector&lt;int&gt; v{1,2,3,4,5,6,7,8,9};<br>
    =C2=A0=C2=A0 <br>
    =C2=A0=C2=A0=C2=A0 printf("%d\n", std::accumulate( v.begin()<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , v.end()<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , 0<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , std::bind(f,_1,_2,=
100,200))); //
    here<br>
    <br>
    =C2=A0=C2=A0=C2=A0 printf("%d\n", std::accumulate( v.begin()<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , v.end()<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , 0<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , [](int x, int y){ =
return
    f(x*y,1,2,3);})); // here<br>
    =C2=A0=C2=A0=C2=A0 return {};<br>
    }<br>
    --- code<br>
    <br>
    I think that it should be clear right now (std::accumulate is doing
    the folding here as is widely known).<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Finally, forcing a constraint over C++'s current lat=
ent 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.
</pre>
      </blockquote>
      <pre wrap=3D"">
I'm not talking about a learning issue, I was asking about the
specification itself.  To me, there's no question that the
concept of a binary function is well-established.</pre>
    </blockquote>
    <br>
    We have been over this quite a few times. We are always talking
    about binary functions, just like the operators are binary. However,
    any kind of n-ary function that can be purposefully transformed into
    a 2-ary through one of the ways we can do partial application. This
    is equally fine since we can provide defaulted arguments, provided
    that such application is being done of course in the correct
    context. The example given before is clear. I am glad that the
    notion of function arity is clear to you, as should be the notion of
    partial application and currying. I tried to avoid using these terms
    (since some C++ programmers insist on them being just "taxonomy" of
    no practical use) but no reason to continue to do so :)<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">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.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">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).
</pre>
      </blockquote>
      <pre wrap=3D"">
I was talking about parsing ambiguities.  I'm still feeling uneasy
here.  Is the "most vexing parse" getting more difficult?</pre>
    </blockquote>
    <br>
    I can very much relate to this because their chosen syntax is
    uneasy, but not exactly ambiguous the way they are tackling it.
    However, it is their proposal, not mine, you should address them on
    that when it comes to the core language group from evolution :). The
    way they play with the parentheses and the triple-dot as tokens
    there is interesting enough. Not going to present an alternative, it
    would mean writing a different paper and I do not wish to do so.<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Sure thing, which means that we are in agreement tha=
t 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,
</pre>
      </blockquote>
      <pre wrap=3D"">
Why?  If you submit the paper now, it certainly has a chance
to get into C++17.</pre>
    </blockquote>
    <br>
    It has to do with this being worthy of the time for doing something
    separate as well as being compatible with whatever agenda there is
    on the matter. I am of those people whose experience with the EWG
    has disillusioned him about whatever integrity certain procedures
    have. So I really do not see the point and let's do not get off
    topic now, you can search the mailing lists for this. You have to be
    part of a lobby in the end with some people and I see no reason to
    invest in building that. It is not that important. I gain zero out
    of this since it neither enhances my knowledge, nor does it give me
    additional credit I do not already have. I just happen to like the
    language despite of its woeful design aspects.<br>
    <br>
    As a library feature, it isn't that this cannot be properly done
    through code generation either through template/constexpr trickery
    etc. If one needs "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 N4191?<br>
    <br>
    <blockquote cite=3D"mid:543F5CF3.6010508@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">  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.
</pre>
      </blockquote>
      <pre wrap=3D"">
Then you should write an e-mail to the authors, maybe they're
sympathetic to your wishes and extend their paper.</pre>
    </blockquote>
    <br>
    Again, unlikely to happen for both parts involved in such a process
    given that I am doubtful of the process that is to be followed in
    its quality and mutual respect. Our discussion was enjoyable indeed.
    I prefer the feedback given on this mailing list.<br>
    <br>
    If I were to work on introducing a construct for folding expressions
    myself, 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 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.<br>
    <br>
    Nothing that metaprogramming can't cover for those of us who may
    wish these things today, despite we don't have them as language
    features. Or perhaps a better language than C++, given that true
    professionals have to be polyglots. So really, why abuse myself in
    any other way other than giving feedback :) It the feedback is good,
    at some point it will be used, whether short-term or long-term. It
    is not that important.<br>
    <br>
    What is important is being honest.<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------060207020700050307000706--


.

On 10/16/2014 12:07 PM, George Makrydakis wrote:
>=20
> 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?
>=20
> You already reply yourself in the following paragraph. An empty list shou=
ld by definition return the identity (e.g. additive, multiplicative etc) of=
 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?

>> 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?
>=20
> 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.

>>>  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.
>=20
> See before, It is not about implicit conversions, it is about the fact th=
at folds on heterogeneous lists can have some interesting properties. This =
should be better discussed in the setting of general catamorphisms. I do no=
t think that discussing it in this setting it would help the discussion. It=
 would confuse people who lack the background (not implying you, I don't kn=
ow you), and my experience with this list shows that most are blissfully un=
aware of these things. Implicit conversions are evil here if not properly m=
anaged.

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?

> It is not my proposal, it is their proposal and I asked why they did not =
consider this or if they will consider it.
>=20
> By definition, you need a binary function in a such fold (I am not saying=
 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 need=
s "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 n=
othing, other than just offering feedback on what is already written in N41=
91?

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.

> If I were to work on introducing a construct for folding expressions myse=
lf, 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 c=
overed equally in all cases. I however do not think that C++ is suitable to=
 such thinking at a language level because some of the people involved in t=
aking decisions have their own ideas on who is allowed to do what - or perh=
aps 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

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

.

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
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878.pdf> and=20
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)             /* 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=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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf>. 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<ArgN,size_t>=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<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=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
<http://en.wikipedia.org/wiki/Monad_%28functional_programming%29>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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <div class=3D"moz-cite-prefix">On 10/16/2014 10:21 PM, Jens Maurer
      wrote:<br>
    </div>
    <blockquote cite=3D"mid:54401A9D.5020808@gmx.net" type=3D"cite">
      <pre wrap=3D"">On 10/16/2014 12:07 PM, George Makrydakis wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">
On 10/16/2014 08:51 AM, Jens Maurer wrote:
</pre>
      </blockquote>
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">That's indeed a good follow-on question: In the fu=
nction case,
what's the result for 0-argument lists?
</pre>
        </blockquote>
        <pre wrap=3D"">
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.
</pre>
      </blockquote>
      <pre wrap=3D"">
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?</pre>
    </blockquote>
    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.<br>
    <blockquote cite=3D"mid:54401A9D.5020808@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <pre wrap=3D"">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?
</pre>
        </blockquote>
        <pre wrap=3D"">
We are not disagreeing, see previous paragraph.
</pre>
      </blockquote>
      <pre wrap=3D"">
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.</pre>
    </blockquote>
    There shouldn't be any constraints in a few words, correct. I am
    over-analyzing it.<br>
    <blockquote cite=3D"mid:54401A9D.5020808@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">
          <blockquote type=3D"cite">
            <pre wrap=3D""> 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.
</pre>
          </blockquote>
          <pre wrap=3D"">Why?  Implicit conversions happen in C++ all the t=
ime.
</pre>
        </blockquote>
        <pre wrap=3D"">
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.
</pre>
      </blockquote>
      <pre wrap=3D"">
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?</pre>
    </blockquote>
    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 <a
      href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3878=
..pdf">N3878</a>
    and a successive revision to do the following with functions:<br>
    <br>
    template&lt;typename A, typename B&gt;<br>
    void fun(A,B) {} /* using void on purpose here of course */<br>
    <br>
    template&lt;typename T&gt;<br>
    int fun(T, T) { /* implementation here */ }<br>
    <br>
    (... fun&lt;auto{T},T&gt; 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 */<br>
    (... fun&lt;auto{A},auto{B}&gt; args) /* the types can be different
    */<br>
    <br>
    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.<br>
    <br>
    <blockquote cite=3D"mid:54401A9D.5020808@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">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),
</pre>
      </blockquote>
      <pre wrap=3D"">
Great.  One more question answered.

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">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?
</pre>
      </blockquote>
      <pre wrap=3D"">
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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    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 <a
      href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701=
..pdf">N3701</a>.
    In page 31 of 56, the authors are effectively performing a fold over
    an argument list using a binary operator (&amp;&amp;). The example
    also implies that 'Args' list had been passed through an fmap
    (structure preserving transformation, "mapping") has been made to a
    Convertible&lt;ArgN,size_t&gt; 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.<br>
    <br>
    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:<br>
    <br>
    template&lt;template&lt;typename&gt; class F, typename... X&gt;<br>
    void fun(F&lt;X&gt;...) {}; /* F&lt;X0&gt;,F&lt;X1&gt;,.... */<br>
    <br>
    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 <a
      href=3D"http://en.wikipedia.org/wiki/Monad_%28functional_programming%=
29"><i>monads</i>
    </a>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.<br>
    <br>
    <blockquote cite=3D"mid:54401A9D.5020808@gmx.net" type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">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.
</pre>
      </blockquote>
      <pre wrap=3D"">
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

</pre>
    </blockquote>
    I do not doubt your motivation. Sorry if I sounded offensive.<br>
    <br>
    In all honesty, I am quite a bit sour from my dealings with the EWG
    and that leads to needless defensivism. <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Regards and good luck,<br>
    <br>
    George<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

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


.

------=_Part_18_1558857186.1413546601663
Content-Type: text/plain; charset=UTF-8

In functional languages, the initial value of a fold can be specified by
the user. Why does the proposal mandate a specific value? Is there anything
that prevents the following syntax:
(args + ... 0) // foldl args (+) 0
(0 ... + args) // foldr args (+) 0
Would this work?

--

---
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_18_1558857186.1413546601663
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In functional languages, the initial value of a fold can b=
e specified by the user. Why does the proposal mandate a specific value? Is=
 there anything that prevents the following syntax:<div><div class=3D"prett=
yprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
rgs </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// foldl args (+) 0</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">0</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> args</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// foldr args (+) 0</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div>Would this work?</div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_18_1558857186.1413546601663--

.