------=_Part_213_5416455.1383037930665
Content-Type: text/plain; charset=ISO-8859-1

Hi there!

I've had this idea in my head for a long time and I'm wondering if it is
worth writing up a proposal. In the following post I am going to try to
explain the basics without going into too much technical details.

The basic idea is to introduce the notion of a macro into the language. A
macro is a constexpr function that - instead of returning something - emits
or injects code at the call site. Let me start out with a simple example:
macro times(unsigned n)
{
    inject "for(unsigned i = 0; i != %, ++i)", n;
}
The inject statement is kind of like a printf statement, the special syntax
allows you to insert the value of an expression into code.

This macro can then be used like this:
$times(10)
    std::cout << "Hello, World!\n";
I propose that the call syntax be different from regular function calls to
make it more clear what's going on. In this case I used the $-sign.
The keywords are of course subject of bikeshedding, I like 'macro' or
'codegen' and 'emit' or 'inject'.

This feature becomes especially powerful with C++14's mutable compiletime
state and upcoming comiletime reflection features. One could easily imagine
iterating over the members of a class to generate comparison operators or
serialization routines using this feature:
The standard library could provide some predefined macros for this.

Is this a feature people would like to have?

--

---
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_213_5416455.1383037930665
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi there!<br><br>I've had this idea in my head for a long =
time and I'm=20
wondering if it is worth writing up a proposal. In the following post I=20
am going to try to explain the basics without going into too much=20
technical details.<br><br>The basic idea is to introduce the notion of a
 macro into the language. A macro is a constexpr function that - instead
 of returning something - emits or injects code at the call site. Let me
 start out with a simple example:<br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">macro times</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">unsigned</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;=
 inject </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"f=
or(unsigned i =3D 0; i !=3D %, ++i)"</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br></span></d=
iv></code></div>The
 inject statement is kind of like a printf statement, the special syntax
 allows you to insert the value of an expression into code.<br><br>This mac=
ro can then be used like this:<br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">$times</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">10</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cou=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">"Hello, World!\n"</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div>I
 propose that the call syntax be different from regular function calls=20
to make it more clear what's going on. In this case I used the $-sign.<br>T=
he keywords are of course subject of bikeshedding, I like 'macro' or 'codeg=
en' and 'emit' or 'inject'.<br><br>This
 feature becomes especially powerful with C++14's mutable compiletime=20
state and upcoming comiletime reflection features. One could easily=20
imagine iterating over the members of a class to generate comparison=20
operators or serialization routines using this feature:<div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-=
by-prettify"></span></code></div>The standard library could provide some pr=
edefined macros for this.<br><br>Is this a feature people would like to hav=
e?<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_213_5416455.1383037930665--

.

------=_Part_57_22812903.1383038269832
Content-Type: text/plain; charset=ISO-8859-1

Whoops! Somehow my last piece of example code got lost. Here it is:
template <typename T>
macro defineEq()
{
    inject "bool operator == (%0 lhs, %0 rhs) { return true", std::meta::
full_name_of<T>();

    for(auto mem : std::meta::members_of<T>())
        inject " && lhs.%0 == rhs.%0", mem.name;

    inject "; }";
}



--

---
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_57_22812903.1383038269832
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><font color=3D"#660066" face=3D"monospace">Whoops! Somehow=
 my last piece of example code got lost. Here it is:</font><br><div><font f=
ace=3D"monospace"><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#000000"><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>macro defineEq</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; inject </span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">"bool operator =3D=3D (%0 lhs, %0 rh=
s) { return true</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">meta</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">full_name_of</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;();</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">for</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> mem </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">meta</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">members_of</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;())</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; inject </span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">" &amp;&amp; lhs.%0 =
=3D=3D rhs.%0"</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mem<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">name</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; inject </span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"; }"</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></font></div></code></div><br><b=
r></font><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_57_22812903.1383038269832--

.

--001a1133073ad24ef604e9de3644
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 10:12 AM, <stackmachine@hotmail.com> wrote:

> Is this a feature people would like to have?


I think you need to clarify how it would differ from the pre-processor
macro and how it would be beneficial compared to, say, templates.

--

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

--001a1133073ad24ef604e9de3644
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Oct 29, 2013 at 10:12 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.com</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Is this a feature people would like to have?=
</blockquote></div><br>I think you need to clarify how it would differ from=
 the pre-processor macro and how it would be beneficial compared to, say, t=
emplates.<br>
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a1133073ad24ef604e9de3644--

.

--047d7bdc96be78385004e9de65ff
Content-Type: text/plain; charset=ISO-8859-1

On 29 October 2013 11:12, <stackmachine@hotmail.com> wrote:

> Hi there!
>
> I've had this idea in my head for a long time and I'm wondering if it is
> worth writing up a proposal. In the following post I am going to try to
> explain the basics without going into too much technical details.
>
> The basic idea is to introduce the notion of a macro into the language. A
> macro is a constexpr function that - instead of returning something - emits
> or injects code at the call site. Let me start out with a simple example:
> macro times(unsigned n)
> {
>     inject "for(unsigned i = 0; i != %, ++i)", n;
> }
> The inject statement is kind of like a printf statement, the special
> syntax allows you to insert the value of an expression into code.
>
> This macro can then be used like this:
> $times(10)
>     std::cout << "Hello, World!\n";
> I propose that the call syntax be different from regular function calls to
> make it more clear what's going on. In this case I used the $-sign.
> The keywords are of course subject of bikeshedding, I like 'macro' or
> 'codegen' and 'emit' or 'inject'.
>
> This feature becomes especially powerful with C++14's mutable compiletime
> state and upcoming comiletime reflection features. One could easily imagine
> iterating over the members of a class to generate comparison operators or
> serialization routines using this feature:
> The standard library could provide some predefined macros for this.
>
> Is this a feature people would like to have?
>
>
>
Certainly. Do explain why it wouldn't be  something like

inline template<unsigned int N> constexpr void times()
// or inline template<> constexpr void times(unsigned int N)

{
    for (unsigned int i = 0; i != N, ++i)
}

?

Now, this is practically a static if for which the condition always
evaluates to true.
And like a static if, it should probably be valid syntactically (which the
example above
isn't), and it should establish a new scope. Otherwise the implementation
problems
of static if will arise again.

--

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

--047d7bdc96be78385004e9de65ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 October 2013 11:12,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.com</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi there=
!<br><br>I&#39;ve had this idea in my head for a long time and I&#39;m=20
wondering if it is worth writing up a proposal. In the following post I=20
am going to try to explain the basics without going into too much=20
technical details.<br><br>The basic idea is to introduce the notion of a
 macro into the language. A macro is a constexpr function that - instead
 of returning something - emits or injects code at the call site. Let me
 start out with a simple example:<br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style>macro times</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">unsign=
ed</span><span style> n</span><span style=3D"color:rgb(102,102,0)">)</span>=
<span style><br>
</span><span style=3D"color:rgb(102,102,0)">{</span><span style><br>=A0 =A0=
 inject </span><span style=3D"color:rgb(0,136,0)">&quot;for(unsigned i =3D =
0; i !=3D %, ++i)&quot;</span><span style=3D"color:rgb(102,102,0)">,</span>=
<span style> n</span><span style=3D"color:rgb(102,102,0)">;</span><span sty=
le><br>
</span><span style=3D"color:rgb(102,102,0)">}</span><span style> <br></span=
></div></code></div>The
 inject statement is kind of like a printf statement, the special syntax
 allows you to insert the value of an expression into code.<br><br>This mac=
ro can then be used like this:<br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word">
<code><div><span style>$times</span><span style=3D"color:rgb(102,102,0)">(<=
/span><span style=3D"color:rgb(0,102,102)">10</span><span style=3D"color:rg=
b(102,102,0)">)</span><span style><br>=A0 =A0 std</span><span style=3D"colo=
r:rgb(102,102,0)">::</span><span style>cout </span><span style=3D"color:rgb=
(102,102,0)">&lt;&lt;</span><span style> </span><span style=3D"color:rgb(0,=
136,0)">&quot;Hello, World!\n&quot;</span><span style=3D"color:rgb(102,102,=
0)">;</span><span style><br>
</span></div></code></div>I
 propose that the call syntax be different from regular function calls=20
to make it more clear what&#39;s going on. In this case I used the $-sign.<=
br>The keywords are of course subject of bikeshedding, I like &#39;macro&#3=
9; or &#39;codegen&#39; and &#39;emit&#39; or &#39;inject&#39;.<br><br>
This
 feature becomes especially powerful with C++14&#39;s mutable compiletime=
=20
state and upcoming comiletime reflection features. One could easily=20
imagine iterating over the members of a class to generate comparison=20
operators or serialization routines using this feature:<div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px;word-wrap:break-word"><code><span style=3D"color:rgb(102=
,102,0)"></span></code></div>
The standard library could provide some predefined macros for this.<br><br>=
Is this a feature people would like to have?<span class=3D""><font color=3D=
"#888888"><br></font></span></div><span class=3D""><font color=3D"#888888">

<p></p>

<br></font></span></blockquote><div><br></div><div>Certainly. Do explain wh=
y it wouldn&#39;t be=A0 something like<br></div></div><br></div><div class=
=3D"gmail_extra">inline template&lt;unsigned int N&gt; constexpr void times=
()<br>
</div><div class=3D"gmail_extra">// or inline template&lt;&gt; constexpr vo=
id times(unsigned int N)<br><br></div><div class=3D"gmail_extra">{<br></div=
><div class=3D"gmail_extra">=A0=A0=A0 for (unsigned int i =3D 0; i !=3D N, =
++i)<br></div>
<div class=3D"gmail_extra">}<br><br>?<br><br></div><div class=3D"gmail_extr=
a">Now, this is practically a static if for which the condition always eval=
uates to true.<br></div><div class=3D"gmail_extra">And like a static if, it=
 should probably be valid syntactically (which the example above<br>
isn&#39;t), and it should establish a new scope. Otherwise the implementati=
on problems<br>of static if will arise again.<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc96be78385004e9de65ff--

.

On 10/29/13 5:12 PM, stackmachine@hotmail.com wrote:
> This feature becomes especially powerful with C++14's mutable compiletime
> state and upcoming comiletime reflection features. One could easily imagi=
ne
> iterating over the members of a class to generate comparison operators or
> serialization routines using this feature:
> The standard library could provide some predefined macros for this.
>
> Is this a feature people would like to have?
>

This has merit, but it would probably be too difficult to add to=20
existing implementations. Assuming you intend for flow control and=20
computation to go into the macro besides the inject statement, the=20
compiler has to fully interpret all definitions up to the current state=20
of the lexer. It's not theoretically impossible, and the march of=20
technology perhaps makes it inevitable, but nobody is in the ballpark yet.

By the way, the current standard requires evaluation of constexpr=20
user-defined literals in #if conditions. I noticed this soon after=20
setting about writing my own preprocessor, and felt like I'd found a=20
wonderful loophole. Alas, it is not the "design intent." Nevertheless,=20
as long as nobody proposes a solution, it remains a requirement for=20
strict compliance.

Thanks for the idea=85 got me thinking about modules=85

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

.

------=_Part_154_24951702.1383049070598
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, October 29, 2013 12:40:57 PM UTC+2, David Krauss wrote:
>
> On 10/29/13 5:12 PM, stackm...@hotmail.com <javascript:> wrote:=20
> > This feature becomes especially powerful with C++14's mutable=20
> compiletime=20
> > state and upcoming comiletime reflection features. One could easily=20
> imagine=20
> > iterating over the members of a class to generate comparison operators=
=20
> or=20
> > serialization routines using this feature:=20
> > The standard library could provide some predefined macros for this.=20
> >=20
> > Is this a feature people would like to have?=20
> >=20
>
[ snip ]=20

>
> Thanks for the idea=EF=BF=BD got me thinking about modules=EF=BF=BD=20
>
>
It just so happens that every time somebody comments on preprocessor=20
deficiencies, a thousand different posts pop up around with alternatives=20
for the sake of good argument. His idea just replaces the current=20
preprocessor, with another preprocessor. Extending one of the type safe=20
metaprogramming features C++ already has would be a more favourable and=20
permanent approach to the problem as a whole. If you start just upgrading=
=20
the preprocessor alone to do more "type safe stuff" and the like, you will=
=20
end up with re - implementing the template system to a point. Why not just=
=20
upgrade the template system itself then and spare yourself the trouble?

I have said myself before in the __VA_NARGS__ thread, once modules kick in,=
=20
it will be a lot clearer what those extensions to the template / constexpr=
=20
metaprogramming facilities should be all about. After all, module proposals=
=20
would  eventually have to deal with partial specializations in the=20
contained instantiations of a given module and so on which themselves would=
=20
require dealing with metaprogramming - wise. This kind of shows the way for=
=20
upgrading the semantics of the current templates system for modules to=20
actually work unambiguously.

So, perhaps this is in the end something that should be considered at some=
=20
point when dealing with modules while showing the preprocessor the way out=
=20
and proposals dealing with either of these issues should explicitely=20
analyze the theoretical implications of said intervention. His idea does=20
not.


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

------=_Part_154_24951702.1383049070598
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 29, 2013 12:40:57 PM UTC+2, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/29/13 5=
:12 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
XYebwCeZ7D0J">stackm...@hotmail.com</a> wrote:
<br>&gt; This feature becomes especially powerful with C++14's mutable comp=
iletime
<br>&gt; state and upcoming comiletime reflection features. One could easil=
y imagine
<br>&gt; iterating over the members of a class to generate comparison opera=
tors or
<br>&gt; serialization routines using this feature:
<br>&gt; The standard library could provide some predefined macros for this=
..
<br>&gt;
<br>&gt; Is this a feature people would like to have?
<br>&gt;
<br></blockquote><div>[ snip ] <br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">
<br>Thanks for the idea=EF=BF=BD got me thinking about modules=EF=BF=BD
<br>
<br></blockquote><div><br>It just so happens that every time somebody comme=
nts on preprocessor deficiencies, a thousand different posts pop up around =
with alternatives for the sake of good argument. His idea just replaces the=
 current preprocessor, with another preprocessor. Extending one of the type=
 safe metaprogramming features C++ already has would be a more favourable a=
nd permanent approach to the problem as a whole. If you start just upgradin=
g the preprocessor alone to do more "type safe stuff" and the like, you wil=
l end up with re - implementing the template system to a point. Why not jus=
t upgrade the template system itself then and spare yourself the trouble?<b=
r><br>I have said myself before in the __VA_NARGS__ thread, once modules ki=
ck in, it will be a lot clearer what those extensions to the template / con=
stexpr metaprogramming facilities should be all about. After all, module pr=
oposals would&nbsp; eventually have to deal with partial specializations in=
 the contained instantiations of a given module and so on which themselves =
would require dealing with metaprogramming - wise. This kind of shows the w=
ay for upgrading the semantics of the current templates system for modules =
to actually work unambiguously.<br><br>So, perhaps this is in the end somet=
hing that should be considered at some point when dealing with modules whil=
e showing the preprocessor the way out and proposals dealing with either of=
 these issues should explicitely analyze the theoretical implications of sa=
id intervention. His idea does not.<br><br><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_154_24951702.1383049070598--

.

------=_Part_161_17299404.1383049429143
Content-Type: text/plain; charset=ISO-8859-1

This is a feature I definitely want to have.
Writing mixins/complex compile-time fuctions/avoiding code repetition can
be painful at times, and adding complex macros does not help readability.
Eventually, I believe C++ needs some language feature like this one.

On Tuesday, 29 October 2013 10:12:10 UTC+1, stackm...@hotmail.com wrote:
>
> Hi there!
>
> I've had this idea in my head for a long time and I'm wondering if it is
> worth writing up a proposal. In the following post I am going to try to
> explain the basics without going into too much technical details.
>
> The basic idea is to introduce the notion of a macro into the language. A
> macro is a constexpr function that - instead of returning something - emits
> or injects code at the call site. Let me start out with a simple example:
> macro times(unsigned n)
> {
>     inject "for(unsigned i = 0; i != %, ++i)", n;
> }
> The inject statement is kind of like a printf statement, the special
> syntax allows you to insert the value of an expression into code.
>
> This macro can then be used like this:
> $times(10)
>     std::cout << "Hello, World!\n";
> I propose that the call syntax be different from regular function calls to
> make it more clear what's going on. In this case I used the $-sign.
> The keywords are of course subject of bikeshedding, I like 'macro' or
> 'codegen' and 'emit' or 'inject'.
>
> This feature becomes especially powerful with C++14's mutable compiletime
> state and upcoming comiletime reflection features. One could easily imagine
> iterating over the members of a class to generate comparison operators or
> serialization routines using this feature:
> The standard library could provide some predefined macros for this.
>
> Is this a feature people would like to have?
>

--

---
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_161_17299404.1383049429143
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is a feature I definitely want to have.&nbsp;<br>Writ=
ing mixins/complex compile-time fuctions/avoiding code repetition can be pa=
inful at times, and adding complex macros does not help readability.&nbsp;<=
br>Eventually, I believe C++ needs some language feature like this one.<br>=
<br>On Tuesday, 29 October 2013 10:12:10 UTC+1, stackm...@hotmail.com  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi there!<b=
r><br>I've had this idea in my head for a long time and I'm=20
wondering if it is worth writing up a proposal. In the following post I=20
am going to try to explain the basics without going into too much=20
technical details.<br><br>The basic idea is to introduce the notion of a
 macro into the language. A macro is a constexpr function that - instead
 of returning something - emits or injects code at the call site. Let me
 start out with a simple example:<br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
;word-wrap:break-word"><code><div><span style=3D"color:#000">macro times</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#008">unsigned<=
/span><span style=3D"color:#000"> n</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"><br>&nbsp; &nbsp; inject </span><span style=3D"c=
olor:#080">"for(unsigned i =3D 0; i !=3D %, ++i)"</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> n</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">}</span><span style=3D"color:#000"> <br></span></div></code></div>The
 inject statement is kind of like a printf statement, the special syntax
 allows you to insert the value of an expression into code.<br><br>This mac=
ro can then be used like this:<br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><span style=3D"color:#000">$times</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#066">10</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"><br>&nbsp; &nbsp; std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">cout =
</span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">"Hello, World!\n"</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br></span></div></code></di=
v>I
 propose that the call syntax be different from regular function calls=20
to make it more clear what's going on. In this case I used the $-sign.<br>T=
he keywords are of course subject of bikeshedding, I like 'macro' or 'codeg=
en' and 'emit' or 'inject'.<br><br>This
 feature becomes especially powerful with C++14's mutable compiletime=20
state and upcoming comiletime reflection features. One could easily=20
imagine iterating over the members of a class to generate comparison=20
operators or serialization routines using this feature:<div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px;word-wrap:break-word"><code><span style=3D"color:#660"><=
/span></code></div>The standard library could provide some predefined macro=
s for this.<br><br>Is this a feature people would like to have?<br></div></=
blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_161_17299404.1383049429143--

.

------=_Part_160_13594928.1383065515481
Content-Type: text/plain; charset=ISO-8859-1

Several thoughts:

1. D language has Mixins, which has very similar use-cases and minimalistic
design: http://dlang.org/mixin.html - it takes compile time string as a
parameter and emits code in-place.
2. This feature is very very powerful. But still - string manipulation is
just the weakest form of metaprogramming.
3. I am sure, with help of mixins it is possible to generate very fast code
in some special cases.
4. Both examples you showed are just not convincing.
a) "times" - such use cases overlaps greatly with lambdas. If you think
that lambdas syntax is noise, then at first we should try to improve it,
like terse notation:
transform(first, last, first, [](x) x*x );
// or
times(10) * [](x) cout << x; // using operator*
b) At defineEq you used compile-time reflection. If we would have it - we
don't need any macros to generate operators/hash functions/serialization -
we could use just something like boost::fusion::fold, which looks much more
prettier than strings injection:
http://coliru.stacked-crooked.com/a/e4dc167785088c81
struct Hasher
{
    template<typename T>
    size_t operator()(size_t hash, T x)
    {
        boost::hash_combine(hash, x);
        return hash;
    }
};

template<typename Struct>
size_t hash_value(const Struct &x)
{
    return boost::fusion::fold(x, size_t(0), Hasher{});
}
5. Every time you want to use macro meta-programming - most likely there is
lack of some good feature in language.

--

---
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_160_13594928.1383065515481
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Several thoughts:<br><br>1. D language has Mixins, which h=
as very similar use-cases and minimalistic design: http://dlang.org/mixin.h=
tml - it takes compile time string as a parameter and emits code in-place.<=
br>2. This feature is very very powerful. But still - string manipulation i=
s just the weakest form of metaprogramming.<br>3. I am sure, with help of m=
ixins it is possible to generate very fast code in some special cases.<br>4=
.. Both examples you showed are just not convincing.<br>a) "times" - such us=
e cases overlaps greatly with lambdas. If you think that lambdas syntax is =
noise, then at first we should try to improve it, like terse notation: <div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">transform</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">first</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: #008;" cla=
ss=3D"styled-by-prettify">last</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> first</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</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">x</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// or</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>times</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">10</span><spa=
n 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: #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">x</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> cout=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><s=
pan 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">// using operator*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><span id=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"h=
ps alt-edited">b) At defineEq you used compile-time reflection. If we would=
 have it - we don't need any macros to generate operators/hash functions/se=
rialization - we could use just something like boost::fusion::fold, which l=
ooks much more prettier than strings injection: http://coliru.stacked-crook=
ed.com/a/e4dc167785088c81<br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Hasher</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">templat=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; size_t </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">size_t hash</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T x</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; boost</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">hash_combine</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">hash</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> hash</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
emplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Struct</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>size_t hash_value</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Struct</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> boost</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">fusion</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">fold</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> size_t</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Hasher</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{});</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span></div></code></div>5. Every time you=
 want to use macro meta-programming - most likely there is lack of some goo=
d feature in language.<br></span></span></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_160_13594928.1383065515481--

.

------=_Part_172_21489718.1383072037739
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, October 29, 2013 9:51:55 AM UTC-7, Evgeny Panasyuk wrote:

> Several thoughts:
>
> 1. D language has Mixins, which has very similar use-cases and
> minimalistic design: http://dlang.org/mixin.html - it takes compile time
> string as a parameter and emits code in-place.
>

Following up on the rest of your points... these are by far my least
favorite feature of D due to the near impossibility of ever being able to
write proper tools for them.  C++ is bad enough here thanks to the
preprocessor and pre-concepts templates.  Existing external code-generation
tools are a nightmare when it comes to debugging typically.
 Maintainability and "toolability" matter more than minor speed gains to
most industries (even performance-oriented ones like games) _way_ more than
gaining a few percent in runtime speed (outside of the most inner of loops,
at least, which typically don't need fancy code generation).

Meta-programming can also be a pain because you can only debug the
resulting code, not the generation of the code (there's no way to step
through template expansions or inspect templates as they're being
evaluated).  This is a problem to look towards fixing, not compounding.
 Exasperating the problem even further by having a glorified M4 macro code
generator in the language forever and ever is a giant leap in the wrong
direction.

I don't think anybody has proposed Mixin-like functionality for C++, but
figured I'd do my best to nip it before it goes anywhere.

--

---
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_172_21489718.1383072037739
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 29, 2013 9:51:55 AM UTC-7, Evgeny Pana=
syuk wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Several thoughts:<br><br>1. D language has Mixins, which has very similar=
 use-cases and minimalistic design: <a href=3D"http://dlang.org/mixin.html"=
 target=3D"_blank">http://dlang.org/mixin.html</a> - it takes compile time =
string as a parameter and emits code in-place.<br></div></blockquote><div><=
br></div><div>Following up on the rest of your points... these are by far m=
y least favorite feature of D due to the near impossibility of ever being a=
ble to write proper tools for them. &nbsp;C++ is bad enough here thanks to =
the preprocessor and pre-concepts templates. &nbsp;Existing external code-g=
eneration tools are a nightmare when it comes to debugging typically. &nbsp=
;Maintainability and "toolability" matter more than minor speed gains to mo=
st industries (even performance-oriented ones like games) _way_ more than g=
aining a few percent in runtime speed (outside of the most inner of loops, =
at least, which typically don't need fancy code generation).</div><div><br>=
</div><div>Meta-programming can also be a pain because you can only debug t=
he resulting code, not the generation of the code (there's no way to step t=
hrough template expansions or inspect templates as they're being evaluated)=
.. &nbsp;This is a problem to look towards fixing, not compounding. &nbsp;Ex=
asperating the problem even further by having a glorified M4 macro code gen=
erator in the language forever and ever is a giant leap in the wrong direct=
ion.</div><div><br></div><div>I don't think anybody has proposed Mixin-like=
 functionality for C++, but figured I'd do my best to nip it before it goes=
 anywhere.</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_172_21489718.1383072037739--

.

------=_Part_1284_9711024.1383118353876
Content-Type: text/plain; charset=ISO-8859-1


>
> I don't think anybody has proposed Mixin-like functionality for C++, but
> figured I'd do my best to nip it before it goes anywhere.
>

Well, while it is nice to have feature - I agree it is very controversial,
and has very low priority.
But I don't think that it will make situation worse. I think it is the
opposite, it will help to simplify code which is already encrypted, and
will help to reduce compile times.
And I think that speed gains will be much bigger than few percents, and
that will enable new EDSLs which were impractical before.
Just think what kind of code libraries like Eigen, Boost.Spirit,
Boost.Xpressive could generate - currently they rely on optimizer and
aggressive inlining, but it has its limits. With help of direct code
injection they can generate *the fastest possible code*.
Yes, certainly that feature will be abused in wrong and unmaintainable ways
- but if somebody will do that, he will deserve what he will get.

--

---
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_1284_9711024.1383118353876
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>I don't think anybody has proposed Mixin-like functionality for C+=
+, but figured I'd do my best to nip it before it goes anywhere.</div></div=
></blockquote><div><br>Well, while it is nice to have feature - I agree it =
is very controversial, and has very low priority.<br>But I don't think that=
 it will make situation worse. I think it is the opposite, it will help to =
simplify code which is already encrypted, and will help to reduce compile t=
imes.<br>And I think that speed gains will be much bigger than few percents=
, and that will enable new EDSLs which were impractical before.<br>Just thi=
nk what kind of code libraries like Eigen, Boost.Spirit, Boost.Xpressive co=
uld generate - currently they rely on optimizer and aggressive inlining, bu=
t it has its limits. With help of direct code injection they can generate <=
b>the fastest possible code</b>.<br>Yes, certainly that feature will be abu=
sed in wrong and unmaintainable ways - but if somebody will do that, he wil=
l deserve what he will get. <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1284_9711024.1383118353876--

.

On Wed, Oct 30, 2013 at 12:32 AM, Evgeny Panasyuk
<evgeny.panasyuk@gmail.com> wrote:
>> I don't think anybody has proposed Mixin-like functionality for C++, but
>> figured I'd do my best to nip it before it goes anywhere.
>
>
> Well, while it is nice to have feature - I agree it is very controversial,
> and has very low priority.
> But I don't think that it will make situation worse. I think it is the
> opposite, it will help to simplify code which is already encrypted, and will
> help to reduce compile times.

You do not appear to be talking about what I'm talking about here.  :)

I am specifically referring to the D-like mixin system, not a
high-level macro system.  Clearly the latter is a good thing to have
compared to what we have today.  D's approach is simply not the right
way to do it.  Rust is a better role model here at a semantics level
(not necessarily the syntax level):
https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md

--

---
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_1213_13676725.1383120356683
Content-Type: text/plain; charset=ISO-8859-1


>
> You do not appear to be talking about what I'm talking about here.  :)
>

I am talking about macro system embedded into language, not external one
like current preprocessor.


> I am specifically referring to the D-like mixin system, not a
> high-level macro system.  Clearly the latter is a good thing to have
> compared to what we have today.  D's approach is simply not the right
> way to do it.  Rust is a better role model here at a semantics level
> (not necessarily the syntax level):
> https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md
>

I think D's mixin is bare minimum which will be feature-enabler.
I am talking about something like:
mixin( constexpr_function_returning_string(arg1, arg2, ag3)  ) // injects
code in-place
//or
mixin( some_struct<arg1, arg2, arg3>::code_string )  // injects code
in-place
Of course higher level macro system will be better, but I guess it will
take much more time to standardize.

--

---
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_1213_13676725.1383120356683
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You do not ap=
pear to be talking about what I'm talking about here. &nbsp;:)
<br></blockquote><div><br>I am talking about macro system embedded into lan=
guage, not external one like current preprocessor.<br>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">I am specifically referring to the D-li=
ke mixin system, not a
<br>high-level macro system. &nbsp;Clearly the latter is a good thing to ha=
ve
<br>compared to what we have today. &nbsp;D's approach is simply not the ri=
ght
<br>way to do it. &nbsp;Rust is a better role model here at a semantics lev=
el
<br>(not necessarily the syntax level):
<br><a href=3D"https://github.com/mozilla/rust/blob/master/doc/tutorial-mac=
ros.md" target=3D"_blank">https://github.com/mozilla/<wbr>rust/blob/master/=
doc/tutorial-<wbr>macros.md</a>
<br></blockquote><div><br>I think D's mixin is bare minimum which will be f=
eature-enabler.<br>I am talking about something like:<br><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">mixin</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> constexpr_function_returning_string</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">arg1</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> arg2</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> ag3</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// injects code=
 in-place</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//or</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>mixin</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> some_struct</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">arg1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> arg2</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> arg3</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">code_string </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// injects code in-place</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div>Of course higher level macro sy=
stem will be better, but I guess it will take much more time to standardize=
..<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1213_13676725.1383120356683--

.

--047d7b10c83def666804e9f4503f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 30, 2013 at 10:05 AM, Evgeny Panasyuk <evgeny.panasyuk@gmail.com
> wrote:

> You do not appear to be talking about what I'm talking about here.  :)
>>
>
> I am talking about macro system embedded into language, not external one
> like current preprocessor.
>

If we are talking about an expression  - tree friendly solution, these
would be far from being just able plain text substitution macros (which are
the problem that causes all others actually). There is a design trilemma
here and it should not be taken lightly if we are to adroitly resolve
systematic code generation issues (not mere text substitution) :

   1. In the eventuality we totally eliminate the preprocessor for when it
   comes to "macros" and we start implementing high level expression tree
   friendly macros with term rewriting features (similar to what Nimrod does
   for example) or even use a more Scala - like approach that is equally
   powerful and type - safe (http://scalamacros.org) that means that we go
   towards a "preprocessor" that starts doing compile - time evaluation within
   macro definitions themselves (and not just in the conditional directives).
   This would mean that we introduce yet another metaprogramming language
   within C++ side to templates and constexpr metaprogramming. It is not
   entirely convincing that we need yet another turing complete (or almost
   turing complete) metalanguage for such a thing since a lot of the features
   it would have to have, in the end would overlap with template
   metaprogramming, first and foremost.
   2. We do not introduce another preprocessor in order to deprecate the
   current one (or extend the current one for that matter) but we do extend /
   modify either or both the template and constexpr metaprogramming facilities
   that are already evolving in the language itself *in such a way as to
   allow for expansion of constructs that are specific to syntactically valid
   and repetitive code constructs commonly used within the language prior to
   any kind of compile time evaluation*. In a sense the semantics of
   parameter unpacking especially when multiple parameter packs are involved (
   http://en.cppreference.com/w/cpp/language/parameter_pack offers a decent
   overview) herald the way of such a thing being not only possible with minor
   syntactic intrusion of new identifiers, but eventually inevitable. And type
   safety in this cases is a given.
   3. Convert the current preprocessor into a turing tarpit by adding small
   features that allow for seriously problematic "solutions" to common
   problems for no other reason than providing evidence that certain things
   are done for the sake of proving cognitive superiority over feeble - minded
   languages like shell scripting oriented ones.

I tend to believe that solution 2 is the more future - proof way of dealing
with such a problem. Template metaprogramming can be characterized as a
pure, non - strict, untyped functional programming language with pattern
matching and I think we have little reason not to expand its semantics to
cover code generation for more complicated constructs. Such "constructs"
already available in valid C++11 where multiple parameter packs are
unpacked in various combinations in a single blow.
*
*
That behaviour is code generation itself introduced because variadic
templates were introduced. Extensions to this way of thinking could
eventually solve some of the problems involved with partial specializations
in modules if they were allowed to expand or modify to type safe constructs
according to input describing module features and facilities (provided they
were within the template system but with semantics and syntax that would
isolate them properly from the rest of the instantiation cascades and their
consequences). This could in the end solve some of the design problems
afflicting modules and the template instantiations they include.


>
>> I am specifically referring to the D-like mixin system, not a
>> high-level macro system.  Clearly the latter is a good thing to have
>> compared to what we have today.  D's approach is simply not the right
>> way to do it.  Rust is a better role model here at a semantics level
>> (not necessarily the syntax level):
>> https://github.com/mozilla/**rust/blob/master/doc/tutorial-**macros.md<https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md>
>>
>
> I think D's mixin is bare minimum which will be feature-enabler.
> I am talking about something like:
> mixin( constexpr_function_returning_string(arg1, arg2, ag3)  ) // injects
> code in-place
> //or
> mixin( some_struct<arg1, arg2, arg3>::code_string )  // injects code
> in-place
> Of course higher level macro system will be better, but I guess it will
> take much more time to standardize.
>
> It would take some deeper analysis on why I believe that D's mixin
solution does not actually help the cause we are after and I am not alone
in this (I think). As for Rust, I reserve my personal opinion until it
reaches 1.0 but if you look at it as it is right now, competent C++
programmers who deploy well - orchestrated preprocessor, template and
constexpr metaprogramming styles - despite the disproportionately tenuous
cognitive overhead for non - experts - end up having superior results.

--

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

--047d7b10c83def666804e9f4503f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Oct 30, 2013 at 10:05 AM, Evgeny Panasyuk <span di=
r=3D"ltr">&lt;<a href=3D"mailto:evgeny.panasyuk@gmail.com" target=3D"_blank=
">evgeny.panasyuk@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You do not appear to be talking about what I&#39;m talking about here. =A0:=
)
<br></blockquote></div><div><br>I am talking about macro system embedded in=
to language, not external one like current preprocessor.<br></div></div></b=
lockquote><div><br></div><div>If we are talking about an expression =A0- tr=
ee friendly solution, these would be far from being just able plain text su=
bstitution macros (which are the problem that causes all others actually). =
There is a design trilemma here and it should not be taken lightly if we ar=
e to adroitly resolve systematic code generation issues (not mere text subs=
titution) :</div>
<div><ol><li>In the eventuality we totally eliminate the preprocessor for w=
hen it comes to &quot;macros&quot; and we start implementing high level exp=
ression tree friendly macros with term rewriting features (similar to what =
Nimrod does for example) or even use a more Scala - like approach that is e=
qually powerful and type - safe (<a href=3D"http://scalamacros.org">http://=
scalamacros.org</a>) that means that we go towards a &quot;preprocessor&quo=
t; that starts doing compile - time evaluation within macro definitions the=
mselves (and not just in the conditional directives). This would mean that =
we introduce yet another metaprogramming language within C++ side to templa=
tes and constexpr metaprogramming. It is not entirely convincing that we ne=
ed yet another turing complete (or almost turing complete) metalanguage for=
 such a thing since a lot of the features it would have to have, in the end=
 would overlap with template metaprogramming, first and foremost.</li>
<li>We do not introduce another preprocessor in order to deprecate the curr=
ent one (or extend the current one for that matter) but we do extend / modi=
fy either or both the template and constexpr metaprogramming facilities tha=
t are already evolving in the language itself <b>in such a way as to allow =
for expansion of constructs that are specific to syntactically valid and re=
petitive code constructs commonly used within the language prior to any kin=
d of compile time evaluation</b>. In a sense the semantics of parameter unp=
acking especially when multiple parameter packs are involved (<a href=3D"ht=
tp://en.cppreference.com/w/cpp/language/parameter_pack">http://en.cpprefere=
nce.com/w/cpp/language/parameter_pack</a>=A0offers a decent overview) heral=
d the way of such a thing being not only possible with minor syntactic intr=
usion of new identifiers, but eventually inevitable. And type safety in thi=
s cases is a given.</li>
<li>Convert the current preprocessor into a turing tarpit by adding small f=
eatures that allow for seriously problematic &quot;solutions&quot; to commo=
n problems for no other reason than providing evidence that certain things =
are done for the sake of proving cognitive superiority over feeble - minded=
 languages like shell scripting oriented ones.</li>
</ol><div>I tend to believe that solution 2 is the more future - proof way =
of dealing with such a problem. Template metaprogramming can be characteriz=
ed as a pure, non - strict, untyped functional programming language with pa=
ttern matching and I think we have little reason not to expand its semantic=
s to cover code generation for more complicated constructs. Such &quot;cons=
tructs&quot; already available in valid C++11 where multiple parameter pack=
s are unpacked in various combinations in a single blow.</div>
<div><b><br></b></div><div>That behaviour is code generation itself introdu=
ced because variadic templates were introduced. Extensions to this way of t=
hinking could eventually solve some of the problems involved with partial s=
pecializations in modules if they were allowed to expand or modify to type =
safe constructs according to input describing module features and facilitie=
s (provided they were within the template system but with semantics and syn=
tax that would isolate them properly from the rest of the instantiation cas=
cades and their consequences). This could in the end solve some of the desi=
gn problems afflicting modules and the template instantiations they include=
..</div>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=A0</div><div c=
lass=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I am specifically referring to the D-like mixin system, no=
t a
<br>high-level macro system. =A0Clearly the latter is a good thing to have
<br>compared to what we have today. =A0D&#39;s approach is simply not the r=
ight
<br>way to do it. =A0Rust is a better role model here at a semantics level
<br>(not necessarily the syntax level):
<br><a href=3D"https://github.com/mozilla/rust/blob/master/doc/tutorial-mac=
ros.md" target=3D"_blank">https://github.com/mozilla/<u></u>rust/blob/maste=
r/doc/tutorial-<u></u>macros.md</a>
<br></blockquote></div><div><br>I think D&#39;s mixin is bare minimum which=
 will be feature-enabler.<br>I am talking about something like:<br><div sty=
le=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);w=
ord-wrap:break-word">
<code><div><span style>mixin</span><span style=3D"color:rgb(102,102,0)">(</=
span><span style> constexpr_function_returning_string</span><span style=3D"=
color:rgb(102,102,0)">(</span><span style>arg1</span><span style=3D"color:r=
gb(102,102,0)">,</span><span style> arg2</span><span style=3D"color:rgb(102=
,102,0)">,</span><span style> ag3</span><span style=3D"color:rgb(102,102,0)=
">)</span><span style> =A0</span><span style=3D"color:rgb(102,102,0)">)</sp=
an><span style> </span><span style=3D"color:rgb(136,0,0)">// injects code i=
n-place</span><span style><br>
</span><span style=3D"color:rgb(136,0,0)">//or</span><span style><br>mixin<=
/span><span style=3D"color:rgb(102,102,0)">(</span><span style> some_struct=
</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style>arg1</sp=
an><span style=3D"color:rgb(102,102,0)">,</span><span style> arg2</span><sp=
an style=3D"color:rgb(102,102,0)">,</span><span style> arg3</span><span sty=
le=3D"color:rgb(102,102,0)">&gt;::</span><span style>code_string </span><sp=
an style=3D"color:rgb(102,102,0)">)</span><span style> =A0</span><span styl=
e=3D"color:rgb(136,0,0)">// injects code in-place</span><span style><br>
</span></div></code></div>Of course higher level macro system will be bette=
r, but I guess it will take much more time to standardize.<br></div></div><=
div class=3D""><div class=3D"h5">

<p></p></div></div></blockquote></div>It would take some deeper analysis on=
 why I believe that D&#39;s mixin solution does not actually help the cause=
 we are after and I am not alone in this (I think). As for Rust, I reserve =
my personal opinion until it reaches 1.0 but if you look at it as it is rig=
ht now, competent C++ programmers who deploy well - orchestrated preprocess=
or, template and constexpr metaprogramming styles - despite the disproporti=
onately tenuous cognitive overhead for non - experts - end up having superi=
or results.</div>
</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b10c83def666804e9f4503f--

.

------=_Part_1163_18343251.1383308659257
Content-Type: text/plain; charset=ISO-8859-1

"How does this differ from preprocessor macros?"
It differs from preprocessor macros in that you can have control flow
withing your macro. This feature is supposed to replace preprocessor macros
completely. It can do anything preprocessor macros can do, except at the
language level, better readable and it is more powerful. Not only that, I'd
also like to get rid of external code generation tools. The fact that
people use these tools indicates a lack of language features.

I agree that strings are not ideal if used directly. The standard could
provide utilities for generating these strings.
template <typename T>
macro generateEq()
{
    std::meta::expression ret = true;

    for(auto mem : std::meta::members_of<T>())
        ret = ret && fb[0].mem == fb[1].mem; // overloaded operators to
build expressions

    std::meta::function_builder<bool(T, T)> fb("operator ==");
    fb.append(std::meta::return_statement(ret));
    inject fb.str();
}
These classes can be built on top of the basic macro system that uses
strings.

Maybe in this specific use case boost::fusion::fold is indeed better. (I
wasn't aware of the existence of it.) But there are a lot of cases where
external code generators are used and I'd like to get rid of the need for
them.

--

---
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_1163_18343251.1383308659257
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">"How does this differ from preprocessor macros?"<br>It dif=
fers from preprocessor macros in that you can have control flow withing you=
r macro. This feature is supposed to replace preprocessor macros=20
completely. It can do anything preprocessor macros can do, except at the
 language level, better readable and it is more powerful. Not only that, I'=
d also like to get rid of external code generation tools. The fact that peo=
ple use these tools indicates a lack of language features.<br><br>I agree t=
hat strings are not ideal if used directly. The standard could provide util=
ities for generating these strings.<br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>ma=
cro generateEq</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">meta</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">expression ret </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> mem </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">meta</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">members_of</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;())</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; ret </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> ret </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> fb</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" cl=
ass=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">].</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">mem </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 fb</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">].</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">mem</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// overloaded operators to build expressions</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span=
><br><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
&nbsp;&nbsp;&nbsp; std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">meta</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">function_b=
uilder</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> fb</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">"operator =3D=3D"</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></code>&nbsp; &nbsp; fb</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">append</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">meta</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">return_statement</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">ret</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; inject fb</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">str</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></div></code></div>These classes can be built on top=
 of the basic macro system that uses strings.<br><br>Maybe in this specific=
 use case boost::fusion::fold is indeed better. (I wasn't aware of the exis=
tence of it.) But there are a lot of cases where external code generators a=
re used and I'd like to get rid of the need for them.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1163_18343251.1383308659257--

.

This is a multi-part message in MIME format.
--------------010507040602060408050306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 01/11/13 13:24, Stack Machine a =E9crit :
> "How does this differ from preprocessor macros?"
> It differs from preprocessor macros in that you can have control flow=20
> withing your macro. This feature is supposed to replace preprocessor=20
> macros completely. It can do anything preprocessor macros can do,=20
> except at the language level, better readable and it is more powerful.=20
> Not only that, I'd also like to get rid of external code generation=20
> tools. The fact that people use these tools indicates a lack of=20
> language features.
>
> I agree that strings are not ideal if used directly. The standard=20
> could provide utilities for generating these strings.
> |
> template<typenameT>
> macro generateEq()
> {
>     std::meta::expression ret =3Dtrue;
>
> for(automem :std::meta::members_of<T>())
>         ret =3Dret &&fb[0].mem =3D=3Dfb[1].mem;// overloaded operators to=
=20
> build expressions
>
> |    std::meta::function_builder<bool(T,T)>fb("operator =3D=3D");
> |    fb.append(std::meta::return_statement(ret));
>     inject fb.str();
> }
> |
> These classes can be built on top of the basic macro system that uses=20
> strings.
>
> Maybe in this specific use case boost::fusion::fold is indeed better.=20
> (I wasn't aware of the existence of it.) But there are a lot of cases=20
> where external code generators are used and I'd like to get rid of the=20
> need for them.
>

Hi,

I have taken a similar approach with what I've called frames. While the=20
example is not enough motivating this big feature, it is simple enough=20
to understand the power of the feature. Instead of macro I have used=20
frame and instead of inject I have used a new operator [[[ ]]].
As your approach, the advantage is the simplicity of the user interface.=20
It allows to mix direct code and transformations using reflection. IMO=20
this interface is closer to the user expectation, as using template=20
meta-programming (in the general case, not this simple case) would be=20
quite complex and request the compiler a lot, well this is what I=20
believe, but I'm not a compiler writer.

To generate the equality operator we can use a *frame* template=20
DefineOperatorEqual that will do what we expect.

struct X {
   int a;
   string b;
*[[[* DefineOperatorEqual<X> *]]]* //or better syntax
};

where

template <typename C>
*frame* DefineOperatorEqual
*(*
***meta::**Id_t ... Member =3D meta::data_members_name_of<C>()**
****) -> meta::function_declaration**_t
****[[[**
*  bool operator =3D=3D (C const& lhs, C const& rhs) {
      return true
*[[[* && lhs.Member =3D=3D rhs.Member *]]]...*
      ;
   }
*]]]*

The use of [[[ and ]]] is deliberated to disambiguate the parser, as a=20
frame transformation can have any C++ code. You ca see it as { }.

We can see a frame as a program transformation, that takes nodes of C++=20
BNF grammar as parameters and return a new node.
The parameter of the preceding frame are Id (as C++ identifiers) that=20
has a default value that depend on the template parameter C.
These Id can be used as any other identifier and the [[[ ]]]=20
transformation will replace them by its respective symbols. This works=20
similar to a macro.

When we want to repeat something on variadic parameters we can use the=20
operator... on the sub-frame we want to repeat enclosed by [[[ ]]].

What do you think?

Best,
Vicente

P.S. I'm working on other cases that would be much more complex using=20
template meta-programming than using this frame concept.
P.P.S. My original frame design was used to also extend the C++ grammar,=20
but this is off topic.

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

--------------010507040602060408050306
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 01/11/13 13:24, Stack Machine a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:0f593183-83f3-4aa2-881d-7837aea2c1c7@isocpp.org"
      type="cite">
      <div dir="ltr">"How does this differ from preprocessor macros?"<br>
        It differs from preprocessor macros in that you can have control
        flow withing your macro. This feature is supposed to replace
        preprocessor macros completely. It can do anything preprocessor
        macros can do, except at the language level, better readable and
        it is more powerful. Not only that, I'd also like to get rid of
        external code generation tools. The fact that people use these
        tools indicates a lack of language features.<br>
        <br>
        I agree that strings are not ideal if used directly. The
        standard could provide utilities for generating these strings.<br>
        <div class="prettyprint" style="background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class="prettyprint">
            <div class="subprettyprint"><span style="color: #008;"
                class="styled-by-prettify">template</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">&lt;</span><span
                style="color: #008;" class="styled-by-prettify">typename</span><span
                style="color: #000;" class="styled-by-prettify"> T</span><span
                style="color: #660;" class="styled-by-prettify">&gt;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
                macro generateEq</span><span style="color: #660;"
                class="styled-by-prettify">()</span><span style="color:
                #000;" class="styled-by-prettify"><br>
              </span><span style="color: #660;"
                class="styled-by-prettify">{</span><span style="color:
                #000;" class="styled-by-prettify"><br>
                &nbsp; &nbsp; std</span><span style="color: #660;"
                class="styled-by-prettify">::</span><span style="color:
                #000;" class="styled-by-prettify">meta</span><span
                style="color: #660;" class="styled-by-prettify">::</span><span
                style="color: #000;" class="styled-by-prettify">expression
                ret </span><span style="color: #660;"
                class="styled-by-prettify">=</span><span style="color:
                #000;" class="styled-by-prettify"> </span><span
                style="color: #008;" class="styled-by-prettify">true</span><span
                style="color: #660;" class="styled-by-prettify">;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
                <br>
                &nbsp; &nbsp; </span><span style="color: #008;"
                class="styled-by-prettify">for</span><span style="color:
                #660;" class="styled-by-prettify">(</span><span
                style="color: #008;" class="styled-by-prettify">auto</span><span
                style="color: #000;" class="styled-by-prettify"> mem </span><span
                style="color: #660;" class="styled-by-prettify">:</span><span
                style="color: #000;" class="styled-by-prettify"> std</span><span
                style="color: #660;" class="styled-by-prettify">::</span><span
                style="color: #000;" class="styled-by-prettify">meta</span><span
                style="color: #660;" class="styled-by-prettify">::</span><span
                style="color: #000;" class="styled-by-prettify">members_of</span><span
                style="color: #660;" class="styled-by-prettify">&lt;</span><span
                style="color: #000;" class="styled-by-prettify">T</span><span
                style="color: #660;" class="styled-by-prettify">&gt;())</span><span
                style="color: #000;" class="styled-by-prettify"><br>
                &nbsp; &nbsp; &nbsp; &nbsp; ret </span><span style="color: #660;"
                class="styled-by-prettify">=</span><span style="color:
                #000;" class="styled-by-prettify"> ret </span><span
                style="color: #660;" class="styled-by-prettify">&amp;&amp;</span><span
                style="color: #000;" class="styled-by-prettify"> fb</span><span
                style="color: #660;" class="styled-by-prettify">[</span><span
                style="color: #066;" class="styled-by-prettify">0</span><span
                style="color: #660;" class="styled-by-prettify">].</span><span
                style="color: #000;" class="styled-by-prettify">mem </span><span
                style="color: #660;" class="styled-by-prettify">==</span><span
                style="color: #000;" class="styled-by-prettify"> fb</span><span
                style="color: #660;" class="styled-by-prettify">[</span><span
                style="color: #066;" class="styled-by-prettify">1</span><span
                style="color: #660;" class="styled-by-prettify">].</span><span
                style="color: #000;" class="styled-by-prettify">mem</span><span
                style="color: #660;" class="styled-by-prettify">;</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #800;" class="styled-by-prettify">//
                overloaded operators to build expressions</span><span
                style="color: #000;" class="styled-by-prettify"><br>
                &nbsp; &nbsp; </span><br>
              <span style="color: #000;" class="styled-by-prettify"><code
                  class="prettyprint"><span style="color: #000;"
                    class="styled-by-prettify">&nbsp;&nbsp;&nbsp; std</span><span
                    style="color: #660;" class="styled-by-prettify">::</span><span
                    style="color: #000;" class="styled-by-prettify">meta</span><span
                    style="color: #660;" class="styled-by-prettify">::</span><span
                    style="color: #000;" class="styled-by-prettify">function_builder</span><span
                    style="color: #660;" class="styled-by-prettify">&lt;</span><span
                    style="color: #008;" class="styled-by-prettify">bool</span><span
                    style="color: #660;" class="styled-by-prettify">(</span><span
                    style="color: #000;" class="styled-by-prettify">T</span><span
                    style="color: #660;" class="styled-by-prettify">,</span><span
                    style="color: #000;" class="styled-by-prettify"> T</span><span
                    style="color: #660;" class="styled-by-prettify">)&gt;</span><span
                    style="color: #000;" class="styled-by-prettify"> fb</span><span
                    style="color: #660;" class="styled-by-prettify">(</span><span
                    style="color: #080;" class="styled-by-prettify">"operator
                    =="</span><span style="color: #660;"
                    class="styled-by-prettify">);</span><span
                    style="color: #000;" class="styled-by-prettify"><br>
                  </span></code>&nbsp; &nbsp; fb</span><span style="color: #660;"
                class="styled-by-prettify">.</span><span style="color:
                #000;" class="styled-by-prettify">append</span><span
                style="color: #660;" class="styled-by-prettify">(</span><span
                style="color: #000;" class="styled-by-prettify">std</span><span
                style="color: #660;" class="styled-by-prettify">::</span><span
                style="color: #000;" class="styled-by-prettify">meta</span><span
                style="color: #660;" class="styled-by-prettify">::</span><span
                style="color: #000;" class="styled-by-prettify">return_statement</span><span
                style="color: #660;" class="styled-by-prettify">(</span><span
                style="color: #000;" class="styled-by-prettify">ret</span><span
                style="color: #660;" class="styled-by-prettify">));</span><span
                style="color: #000;" class="styled-by-prettify"><br>
                &nbsp; &nbsp; inject fb</span><span style="color: #660;"
                class="styled-by-prettify">.</span><span style="color:
                #000;" class="styled-by-prettify">str</span><span
                style="color: #660;" class="styled-by-prettify">();</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span><span style="color: #660;"
                class="styled-by-prettify">}</span><span style="color:
                #000;" class="styled-by-prettify"><br>
              </span></div>
          </code></div>
        These classes can be built on top of the basic macro system that
        uses strings.<br>
        <br>
        Maybe in this specific use case boost::fusion::fold is indeed
        better. (I wasn't aware of the existence of it.) But there are a
        lot of cases where external code generators are used and I'd
        like to get rid of the need for them.<br>
      </div>
      <br>
    </blockquote>
    <br>
    Hi,<br>
    <br>
    I have taken a similar approach with what I've called frames. While
    the example is not enough motivating this big feature, it is simple
    enough to understand the power of the feature. Instead of macro I
    have used frame and instead of inject I have used a new operator [[[
    ]]].<br>
    As your approach, the advantage is the simplicity of the user
    interface. It allows to mix direct code and transformations using
    reflection. IMO this interface is closer to the user expectation, as
    using template meta-programming (in the general case, not this
    simple case) would be quite complex and request the compiler a lot,
    well this is what I believe, but I'm not a compiler writer.<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    To generate the equality operator we can use a <b>frame</b>
    template DefineOperatorEqual that will do what we expect.<br>
    <br>
    struct X {<br>
    &nbsp; int a;<br>
    &nbsp; string b;<br>
    <font color="#3333ff">
      &nbsp; <b>[[[</b> DefineOperatorEqual&lt;X&gt; <b>]]]</b> //or better
      syntax</font><br>
    };<br>
    <br>
    where <br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    template &lt;typename C&gt;<br>
    <font color="#3333ff"><b>frame</b></font> DefineOperatorEqual<br>
    <font color="#3333ff"><b>(</b></font><br>
    <font color="#3333ff"><b>&nbsp;&nbsp;&nbsp; </b><b>meta::</b><b>Id_t ... Member =
        meta::data_members_name_of&lt;C&gt;()</b><b><br>
      </b><b>
      </b><b>) -&gt; meta::function_declaration</b><b>_t<br>
      </b><b>
      </b><b>[[[</b><b><br>
      </b></font>&nbsp; bool operator == (C const&amp; lhs, C const&amp; rhs)
    {<br>
    &nbsp;&nbsp;&nbsp;&nbsp; return true<br>
    &nbsp;&nbsp;&nbsp;&nbsp;
    <font color="#3333ff">
      <b>[[[</b> </font>&amp;&amp; lhs.Member == rhs.Member <font
      color="#3333ff"><b>]]]...</b></font><br>
    &nbsp;&nbsp;&nbsp;&nbsp; ;<br>
    &nbsp; }<br>
    <font color="#3333ff"><b>]]]</b><br>
    </font><br>
    The use of [[[ and ]]] is deliberated to disambiguate the parser, as
    a frame transformation can have any C++ code. You ca see it as { }.<br>
    <br>
    We can see a frame as a program transformation, that takes nodes of
    C++ BNF grammar as parameters and return a new node.<br>
    The parameter of the preceding frame are Id (as C++ identifiers)
    that has a default value that depend on the template parameter C.<br>
    These Id can be used as any other identifier and the [[[ ]]]
    transformation will replace them by its respective symbols. This
    works similar to a macro.<br>
    <br>
    When we want to repeat something on variadic parameters we can use
    the operator... on the sub-frame we want to repeat enclosed by [[[
    ]]].<wbr><br>
    <br>
    What do you think?<br>
    <br>
    Best,<br>
    Vicente<br>
    <br>
    P.S. I'm working on other cases that would be much more complex
    using template meta-programming than using this frame concept.<br>
    P.P.S. My original frame design was used to also extend the C++
    grammar, but this is off topic.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------010507040602060408050306--

.

This is a multi-part message in MIME format.
--------------080302040508030100010704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 01/11/13 20:13, Vicente J. Botet Escriba a =E9crit :
> Le 01/11/13 13:24, Stack Machine a =E9crit :
>> "How does this differ from preprocessor macros?"
>> It differs from preprocessor macros in that you can have control flow=20
>> withing your macro. This feature is supposed to replace preprocessor=20
>> macros completely. It can do anything preprocessor macros can do,=20
>> except at the language level, better readable and it is more=20
>> powerful. Not only that, I'd also like to get rid of external code=20
>> generation tools. The fact that people use these tools indicates a=20
>> lack of language features.
>>
>> I agree that strings are not ideal if used directly. The standard=20
>> could provide utilities for generating these strings.
>> |
>> template<typenameT>
>> macro generateEq()
>> {
>>     std::meta::expression ret =3Dtrue;
>>
>> for(automem :std::meta::members_of<T>())
>>         ret =3Dret &&fb[0].mem =3D=3Dfb[1].mem;// overloaded operators t=
o=20
>> build expressions
>>
>> |    std::meta::function_builder<bool(T,T)>fb("operator =3D=3D");
>> |    fb.append(std::meta::return_statement(ret));
>>     inject fb.str();
>> }
>> |
>> These classes can be built on top of the basic macro system that uses=20
>> strings.
>>
>> Maybe in this specific use case boost::fusion::fold is indeed better.=20
>> (I wasn't aware of the existence of it.) But there are a lot of cases=20
>> where external code generators are used and I'd like to get rid of=20
>> the need for them.
>>
>
> Hi,
>
> I have taken a similar approach with what I've called frames. While=20
> the example is not enough motivating this big feature, it is simple=20
> enough to understand the power of the feature. Instead of macro I have=20
> used frame and instead of inject I have used a new operator [[[ ]]].
> As your approach, the advantage is the simplicity of the user=20
> interface. It allows to mix direct code and transformations using=20
> reflection. IMO this interface is closer to the user expectation, as=20
> using template meta-programming (in the general case, not this simple=20
> case) would be quite complex and request the compiler a lot, well this=20
> is what I believe, but I'm not a compiler writer.
>
> To generate the equality operator we can use a *frame* template=20
> DefineOperatorEqual that will do what we expect.
>
> struct X {
>   int a;
>   string b;
> *[[[* DefineOperatorEqual<X> *]]]* //or better syntax
> };
>
> where
>
> template <typename C>
> *frame* DefineOperatorEqual
> *(*
> ***meta::**Id_t ... Member =3D meta::data_members_name_of<C>()**
> ****) -> meta::function_declaration**_t
> ****[[[**
> *  bool operator =3D=3D (C const& lhs, C const& rhs) {
>      return true
> *[[[* && lhs.Member =3D=3D rhs.Member *]]]...*
>      ;
>   }
> *]]]*
>
> The use of [[[ and ]]] is deliberated to disambiguate the parser, as a=20
> frame transformation can have any C++ code. You ca see it as { }.
>
> We can see a frame as a program transformation, that takes nodes of=20
> C++ BNF grammar as parameters and return a new node.
> The parameter of the preceding frame are Id (as C++ identifiers) that=20
> has a default value that depend on the template parameter C.
> These Id can be used as any other identifier and the [[[ ]]]=20
> transformation will replace them by its respective symbols. This works=20
> similar to a macro.
>
> When we want to repeat something on variadic parameters we can use the=20
> operator... on the sub-frame we want to repeat enclosed by [[[ ]]].
>
> What do you think?
>
> Best,
> Vicente
>
> P.S. I'm working on other cases that would be much more complex using=20
> template meta-programming than using this frame concept.
>
>
Hi, here it is

the example is related to the use case of calling a specific function=20
before delegating.
Given

#include <delegate>
class C {
public:
int i;
void f();
vector<int> g(double);
private:
void h(int);
};

The generic delegate_before_call<C,F,B> should be identical to the=20
manual specialization below

template<class F, class B>
class delegate_before_call<C, F, B> : public B
{
   using this_type =3D delegate_before<C, F, B>;
   friend F;
public:
   delegate_before_call(C &c, F f) : wrapped(c), fct(f) {}
   void f() {
     fct( ); // (1.a)
     wrapped.f();
   }
   vector<int> g(double d) {
     fct( ); // [2.a]
     return wrapped.g(d);
   }
};

Using the frame the solution almost as short as if we made the=20
specialization by hand


template<class T>
*frame*delegate_members_before_call[
meta::member_function ...Member =3D meta::public_function_members_of<T> >
] -> DeclarationList
*[[[
   [[[
   Member::signature*{
     fct( );
     return wrapped.*Member::forward_call()*;
   }
*  ]]]...
]]]*

template<class T, class F, class B>
class delegate_before_call : public B
{
   using this_type =3D delegate_before_call<T, F, B>;
   friend F;
public:
   delegate_before(C &c, F f) : wrapped(c), fct(f) {}
*[[[ delegate_members_before_call<T>[] ]]]
*};

This is simple for the user. Maybe complex for the compiler.

I have found a lot of difficulties to find a good design for solving=20
this problem without this new frame feature.
How to generate the definition of the new function?

vector<int> g(double d) {
     fct( );
     return wrapped.g(d);
   }

Using lambdas?

How to include these function definitions in the new class? Using an=20
inheritance hierarchy has some troubles with the wrapped overloaded=20
functions, as show by Boost.TypeErasure implementation?

IMO, mixing code and [[[reification]]] via frames is the way to go so=20
solve these kind of problems.

I would like to see what other can propose using know template=20
meta-programming techniques.

Best,
Vicente


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

--------------080302040508030100010704
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 01/11/13 20:13, Vicente J. Botet
      Escriba a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote cite="mid:5273FD69.90406@wanadoo.fr" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Le 01/11/13 13:24, Stack Machine a
        &eacute;crit&nbsp;:<br>
      </div>
      <blockquote
        cite="mid:0f593183-83f3-4aa2-881d-7837aea2c1c7@isocpp.org"
        type="cite">
        <div dir="ltr">"How does this differ from preprocessor macros?"<br>
          It differs from preprocessor macros in that you can have
          control flow withing your macro. This feature is supposed to
          replace preprocessor macros completely. It can do anything
          preprocessor macros can do, except at the language level,
          better readable and it is more powerful. Not only that, I'd
          also like to get rid of external code generation tools. The
          fact that people use these tools indicates a lack of language
          features.<br>
          <br>
          I agree that strings are not ideal if used directly. The
          standard could provide utilities for generating these strings.<br>
          <div class="prettyprint" style="background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code
              class="prettyprint">
              <div class="subprettyprint"><span style="color: #008;"
                  class="styled-by-prettify">template</span><span
                  style="color: #000;" class="styled-by-prettify"> </span><span
                  style="color: #660;" class="styled-by-prettify">&lt;</span><span
                  style="color: #008;" class="styled-by-prettify">typename</span><span
                  style="color: #000;" class="styled-by-prettify"> T</span><span
                  style="color: #660;" class="styled-by-prettify">&gt;</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  macro generateEq</span><span style="color: #660;"
                  class="styled-by-prettify">()</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                </span><span style="color: #660;"
                  class="styled-by-prettify">{</span><span style="color:
                  #000;" class="styled-by-prettify"><br>
                  &nbsp; &nbsp; std</span><span style="color: #660;"
                  class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">meta</span><span
                  style="color: #660;" class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">expression

                  ret </span><span style="color: #660;"
                  class="styled-by-prettify">=</span><span style="color:
                  #000;" class="styled-by-prettify"> </span><span
                  style="color: #008;" class="styled-by-prettify">true</span><span
                  style="color: #660;" class="styled-by-prettify">;</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  <br>
                  &nbsp; &nbsp; </span><span style="color: #008;"
                  class="styled-by-prettify">for</span><span
                  style="color: #660;" class="styled-by-prettify">(</span><span
                  style="color: #008;" class="styled-by-prettify">auto</span><span
                  style="color: #000;" class="styled-by-prettify"> mem </span><span
                  style="color: #660;" class="styled-by-prettify">:</span><span
                  style="color: #000;" class="styled-by-prettify"> std</span><span
                  style="color: #660;" class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">meta</span><span
                  style="color: #660;" class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">members_of</span><span
                  style="color: #660;" class="styled-by-prettify">&lt;</span><span
                  style="color: #000;" class="styled-by-prettify">T</span><span
                  style="color: #660;" class="styled-by-prettify">&gt;())</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  &nbsp; &nbsp; &nbsp; &nbsp; ret </span><span style="color: #660;"
                  class="styled-by-prettify">=</span><span style="color:
                  #000;" class="styled-by-prettify"> ret </span><span
                  style="color: #660;" class="styled-by-prettify">&amp;&amp;</span><span
                  style="color: #000;" class="styled-by-prettify"> fb</span><span
                  style="color: #660;" class="styled-by-prettify">[</span><span
                  style="color: #066;" class="styled-by-prettify">0</span><span
                  style="color: #660;" class="styled-by-prettify">].</span><span
                  style="color: #000;" class="styled-by-prettify">mem </span><span
                  style="color: #660;" class="styled-by-prettify">==</span><span
                  style="color: #000;" class="styled-by-prettify"> fb</span><span
                  style="color: #660;" class="styled-by-prettify">[</span><span
                  style="color: #066;" class="styled-by-prettify">1</span><span
                  style="color: #660;" class="styled-by-prettify">].</span><span
                  style="color: #000;" class="styled-by-prettify">mem</span><span
                  style="color: #660;" class="styled-by-prettify">;</span><span
                  style="color: #000;" class="styled-by-prettify"> </span><span
                  style="color: #800;" class="styled-by-prettify">//
                  overloaded operators to build expressions</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  &nbsp; &nbsp; </span><br>
                <span style="color: #000;" class="styled-by-prettify"><code
                    class="prettyprint"><span style="color: #000;"
                      class="styled-by-prettify">&nbsp;&nbsp;&nbsp; std</span><span
                      style="color: #660;" class="styled-by-prettify">::</span><span
                      style="color: #000;" class="styled-by-prettify">meta</span><span
                      style="color: #660;" class="styled-by-prettify">::</span><span
                      style="color: #000;" class="styled-by-prettify">function_builder</span><span
                      style="color: #660;" class="styled-by-prettify">&lt;</span><span
                      style="color: #008;" class="styled-by-prettify">bool</span><span
                      style="color: #660;" class="styled-by-prettify">(</span><span
                      style="color: #000;" class="styled-by-prettify">T</span><span
                      style="color: #660;" class="styled-by-prettify">,</span><span
                      style="color: #000;" class="styled-by-prettify"> T</span><span
                      style="color: #660;" class="styled-by-prettify">)&gt;</span><span
                      style="color: #000;" class="styled-by-prettify">
                      fb</span><span style="color: #660;"
                      class="styled-by-prettify">(</span><span
                      style="color: #080;" class="styled-by-prettify">"operator

                      =="</span><span style="color: #660;"
                      class="styled-by-prettify">);</span><span
                      style="color: #000;" class="styled-by-prettify"><br>
                    </span></code>&nbsp; &nbsp; fb</span><span style="color:
                  #660;" class="styled-by-prettify">.</span><span
                  style="color: #000;" class="styled-by-prettify">append</span><span
                  style="color: #660;" class="styled-by-prettify">(</span><span
                  style="color: #000;" class="styled-by-prettify">std</span><span
                  style="color: #660;" class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">meta</span><span
                  style="color: #660;" class="styled-by-prettify">::</span><span
                  style="color: #000;" class="styled-by-prettify">return_statement</span><span
                  style="color: #660;" class="styled-by-prettify">(</span><span
                  style="color: #000;" class="styled-by-prettify">ret</span><span
                  style="color: #660;" class="styled-by-prettify">));</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                  &nbsp; &nbsp; inject fb</span><span style="color: #660;"
                  class="styled-by-prettify">.</span><span style="color:
                  #000;" class="styled-by-prettify">str</span><span
                  style="color: #660;" class="styled-by-prettify">();</span><span
                  style="color: #000;" class="styled-by-prettify"><br>
                </span><span style="color: #660;"
                  class="styled-by-prettify">}</span><span style="color:
                  #000;" class="styled-by-prettify"><br>
                </span></div>
            </code></div>
          These classes can be built on top of the basic macro system
          that uses strings.<br>
          <br>
          Maybe in this specific use case boost::fusion::fold is indeed
          better. (I wasn't aware of the existence of it.) But there are
          a lot of cases where external code generators are used and I'd
          like to get rid of the need for them.<br>
        </div>
        <br>
      </blockquote>
      <br>
      Hi,<br>
      <br>
      I have taken a similar approach with what I've called frames.
      While the example is not enough motivating this big feature, it is
      simple enough to understand the power of the feature. Instead of
      macro I have used frame and instead of inject I have used a new
      operator [[[ ]]].<br>
      As your approach, the advantage is the simplicity of the user
      interface. It allows to mix direct code and transformations using
      reflection. IMO this interface is closer to the user expectation,
      as using template meta-programming (in the general case, not this
      simple case) would be quite complex and request the compiler a
      lot, well this is what I believe, but I'm not a compiler writer.<br>
      <br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      To generate the equality operator we can use a <b>frame</b>
      template DefineOperatorEqual that will do what we expect.<br>
      <br>
      struct X {<br>
      &nbsp; int a;<br>
      &nbsp; string b;<br>
      <font color="#3333ff"> &nbsp; <b>[[[</b> DefineOperatorEqual&lt;X&gt;
        <b>]]]</b> //or better syntax</font><br>
      };<br>
      <br>
      where <br>
      <br>
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      template &lt;typename C&gt;<br>
      <font color="#3333ff"><b>frame</b></font> DefineOperatorEqual<br>
      <font color="#3333ff"><b>(</b></font><br>
      <font color="#3333ff"><b>&nbsp;&nbsp;&nbsp; </b><b>meta::</b><b>Id_t ... Member
          = meta::data_members_name_of&lt;C&gt;()</b><b><br>
        </b><b> </b><b>) -&gt; meta::function_declaration</b><b>_t<br>
        </b><b> </b><b>[[[</b><b><br>
        </b></font>&nbsp; bool operator == (C const&amp; lhs, C const&amp;
      rhs) {<br>
      &nbsp;&nbsp;&nbsp;&nbsp; return true<br>
      &nbsp;&nbsp;&nbsp;&nbsp; <font color="#3333ff"> <b>[[[</b> </font>&amp;&amp;
      lhs.Member == rhs.Member <font color="#3333ff"><b>]]]...</b></font><br>
      &nbsp;&nbsp;&nbsp;&nbsp; ;<br>
      &nbsp; }<br>
      <font color="#3333ff"><b>]]]</b><br>
      </font><br>
      The use of [[[ and ]]] is deliberated to disambiguate the parser,
      as a frame transformation can have any C++ code. You ca see it as
      { }.<br>
      <br>
      We can see a frame as a program transformation, that takes nodes
      of C++ BNF grammar as parameters and return a new node.<br>
      The parameter of the preceding frame are Id (as C++ identifiers)
      that has a default value that depend on the template parameter C.<br>
      These Id can be used as any other identifier and the [[[ ]]]
      transformation will replace them by its respective symbols. This
      works similar to a macro.<br>
      <br>
      When we want to repeat something on variadic parameters we can use
      the operator... on the sub-frame we want to repeat enclosed by [[[
      ]]].<wbr><br>
      <br>
      What do you think?<br>
      <br>
      Best,<br>
      Vicente<br>
      <br>
      P.S. I'm working on other cases that would be much more complex
      using template meta-programming than using this frame concept.<br>
      <br>
      <br>
    </blockquote>
    <font size="+1">Hi, here it is <br>
      <br>
      the example is related to the use case of calling a specific
      function before delegating.<br>
      <big><font style="font-size: 9pt"><font face="Times New Roman,
            serif">Given</font></font>
      </big></font>
    <p style="margin-left: 1.25cm"><big><font face="Courier New,
          monospace" size="+1"><big><font style="font-size: 9pt">#include
              &lt;delegate&gt;<br>
              class C {<br>
              public:<br>
              int i;<br>
              void f();<br>
              vector&lt;int&gt; g(double);<br>
              private:<br>
              void h(int);<br>
              };</font></big></font></big></p>
    <big><font size="+1"><big>
          <font style="font-size: 9pt">The generic
            <font face="Courier New, monospace">delegate_before_call&lt;C,F,B&gt;</font>
            should be identical to the manual specialization below</font>
        </big></font></big>
    <title></title>
    <meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
    <style type="text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style>
    <p style="margin-left: 1.25cm"><big><font face="Courier New,
          monospace" size="+1"><big><font style="font-size: 9pt">template&lt;class
F,
              class B&gt;<br>
              class delegate_before_call&lt;C, F, B&gt; : public
              B<br>
              {<br>
              &nbsp; using this_type = delegate_before&lt;C, F, B&gt;;<br>
              &nbsp; friend F;<br>
              public:<br>
              &nbsp; delegate_before_call(C &amp;c, F f) :
              wrapped(c), fct(f) {}<br>
              &nbsp; void f() {<br>
              &nbsp;&nbsp;&nbsp; fct( ); // (1.a)<br>
              &nbsp;&nbsp;&nbsp; wrapped.f();<br>
              &nbsp; }<br>
              &nbsp; vector&lt;int&gt; g(double d) {<br>
              &nbsp;&nbsp;&nbsp; fct( ); // [2.a]<br>
              &nbsp;&nbsp;&nbsp; return wrapped.g(d);<br>
              &nbsp; }<br>
              };</font></big></font></big></p>
    <font size="+1">
      Using the frame the solution almost as short as if we made the
      specialization by hand<br>
    </font>
    <title></title>
    <meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
    <style type="text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style>
    <p style="margin-left: 1.25cm"><font face="Courier New, monospace"
        size="+1"><font style="font-size: 9pt"><br>
        </font></font><font size="+1"><font style="font-size: 9pt"><tt><big>template&lt;class
              T&gt;<br>
            </big></tt></font></font><tt><big><font size="+1"><big><font
                style="font-size: 9pt"><b>frame</b></font></big></font><font
            size="+1"><big><font style="font-size: 9pt">
                delegate_members_before_call[<br>
                meta::member_function
                ...Member = meta::public_function_members_of&lt;T&gt;
                &gt;<br>
                ]
                -&gt; DeclarationList<br>
              </font></big></font><font size="+1"><big><font
                style="font-size: 9pt"><b>[[[
                  <br>
                  &nbsp; [[[ <br>
                  &nbsp; Member::signature</b></font></big></font><font
            size="+1"><big><font style="font-size: 9pt">
                {<br>
                &nbsp; &nbsp; fct( </font></big></font><font size="+1"><big><font
                style="font-size: 9pt">);<br>
                &nbsp;&nbsp;&nbsp; return wrapped.</font></big></font><font size="+1"><big><font
                style="font-size: 9pt"><b>Member::forward_call()</b></font></big></font><font
            size="+1"><big><font style="font-size: 9pt">
                ;<br>
                &nbsp; }<br>
              </font></big></font><font size="+1"><big><font
                style="font-size: 9pt"><b>&nbsp; ]]]...<br>
                  ]]]</b></font></big></font></big></tt></p>
    <tt><big><font size="+1"><big>
          </big></font></big></tt>
    <p style="margin-left: 1.25cm"><tt><big><font size="+1"><big><font
                style="font-size: 9pt">template&lt;class
                T, class F, class B&gt;<br>
                class delegate_before_call : public B<br>
                {<br>
                &nbsp; using this_type = delegate_before_call&lt;T, F, B&gt;;<br>
                &nbsp; friend
                F;<br>
                public:<br>
                &nbsp; delegate_before(C &amp;c, F f) : wrapped(c),
                fct(f) {}</font><br>
              <small>&nbsp;</small><font style="font-size: 8pt"><font
                  style="font-size: 9pt"><b><small>[[[
                      delegate_members_before_call&lt;T&gt;[] ]]]</small><br>
                  </b></font><font style="font-size: 9pt">};</font></font></big></font></big></tt></p>
    <font size="+1">
      This is simple for the user. Maybe complex for the compiler.<br>
      <br>
      I have found a lot of difficulties to find a good design for
      solving this problem without this new frame feature.<br>
      How to generate the definition of the new function?&nbsp; <br>
      <br>
      <font face="Courier New, monospace"><font style="font-size: 9pt"><big>&nbsp;
            vector&lt;int&gt; g(double d) {<br>
            &nbsp;&nbsp;&nbsp; fct( ); <br>
            &nbsp;&nbsp;&nbsp; return wrapped.g(d);<br>
            &nbsp; }<br>
            <br>
          </big></font></font></font>
    <title></title>
    <meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
    <style type="text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->?</style><big><big><font style="font-size: 9pt" size="+2">Using
          lambdas?</font><font style="font-size: 9pt" size="+2"><br>
          <br>
          How to include these function definitions in the new class?
          Using an inheritance hierarchy has some troubles with the
          wrapped overloaded functions, as show by Boost.TypeErasure
          implementation?<br>
          <br>
          IMO, mixing code and [[[reification]]] via frames is the way
          to go so solve these kind of problems. <br>
          <br>
          I would like to see what other can propose using know template
          meta-programming techniques.<br>
          <br>
          Best,<br>
          Vicente</font><font style="font-size: 9pt" size="+2"><br>
        </font><font face="Courier New, monospace"><font
            style="font-size: 9pt" size="2"><big><big><br>
                <br>
              </big></big></font></font></big></big>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------080302040508030100010704--

.

------TDR5S1HHS640W2VPUCPCZKBHY96PJR
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Please clarify whether "frame" and your proposed "operator [[[ ]]]" work as=
 cues for expanding code constructs that are respecting type safety / langu=
age grammar and when should such operations take place.

It seems that you are you just adroitly attempting to move function - like =
macro definition and invocation in a form of expansion within the definitio=
n scope of class / function templates, while giving some constant expressio=
n evaluation characteristics in said operation.

Should that hold, you would just be forcing tightly coupled evaluations to =
occur prior to template instantiation and even definition. Have you conside=
red where such a way would clash with templates / constexpr ?

I am just saying that by wanting to remove the need for preprocessor metapr=
ogramming with the current facilities, in the end the route is to augment c=
onstexpr / template metaprogramming, not introduce another preprocessor.

I would thus like to see where this unambiguously extends templates and con=
stexpr and how it deals with the simple degenerate case of plain text subst=
itution and concatenation, even when the strings in question are totally ra=
ndom (just like what happens with the preprocessor now).

As for people who rely on external tools for code generation, I think they =
are simply trying to avoid current preprocessor metaprogramming techniques =
for some subjective disadvantage. Examples like boost's own use demonstrate=
s otherwise.


"Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
>Le 01/11/13 20:13, Vicente J. Botet Escriba a =E9crit :
>> Le 01/11/13 13:24, Stack Machine a =E9crit :
>>> "How does this differ from preprocessor macros?"
>>> It differs from preprocessor macros in that you can have control
>flow=20
>>> withing your macro. This feature is supposed to replace preprocessor
>
>>> macros completely. It can do anything preprocessor macros can do,=20
>>> except at the language level, better readable and it is more=20
>>> powerful. Not only that, I'd also like to get rid of external code=20
>>> generation tools. The fact that people use these tools indicates a=20
>>> lack of language features.
>>>
>>> I agree that strings are not ideal if used directly. The standard=20
>>> could provide utilities for generating these strings.
>>> |
>>> template<typenameT>
>>> macro generateEq()
>>> {
>>>     std::meta::expression ret =3Dtrue;
>>>
>>> for(automem :std::meta::members_of<T>())
>>>         ret =3Dret &&fb[0].mem =3D=3Dfb[1].mem;// overloaded operators =
to=20
>>> build expressions
>>>
>>> |    std::meta::function_builder<bool(T,T)>fb("operator =3D=3D");
>>> |    fb.append(std::meta::return_statement(ret));
>>>     inject fb.str();
>>> }
>>> |
>>> These classes can be built on top of the basic macro system that
>uses=20
>>> strings.
>>>
>>> Maybe in this specific use case boost::fusion::fold is indeed
>better.=20
>>> (I wasn't aware of the existence of it.) But there are a lot of
>cases=20
>>> where external code generators are used and I'd like to get rid of=20
>>> the need for them.
>>>
>>
>> Hi,
>>
>> I have taken a similar approach with what I've called frames. While=20
>> the example is not enough motivating this big feature, it is simple=20
>> enough to understand the power of the feature. Instead of macro I
>have=20
>> used frame and instead of inject I have used a new operator [[[ ]]].
>> As your approach, the advantage is the simplicity of the user=20
>> interface. It allows to mix direct code and transformations using=20
>> reflection. IMO this interface is closer to the user expectation, as=20
>> using template meta-programming (in the general case, not this simple
>
>> case) would be quite complex and request the compiler a lot, well
>this=20
>> is what I believe, but I'm not a compiler writer.
>>
>> To generate the equality operator we can use a *frame* template=20
>> DefineOperatorEqual that will do what we expect.
>>
>> struct X {
>>   int a;
>>   string b;
>> *[[[* DefineOperatorEqual<X> *]]]* //or better syntax
>> };
>>
>> where
>>
>> template <typename C>
>> *frame* DefineOperatorEqual
>> *(*
>> ***meta::**Id_t ... Member =3D meta::data_members_name_of<C>()**
>> ****) -> meta::function_declaration**_t
>> ****[[[**
>> *  bool operator =3D=3D (C const& lhs, C const& rhs) {
>>      return true
>> *[[[* && lhs.Member =3D=3D rhs.Member *]]]...*
>>      ;
>>   }
>> *]]]*
>>
>> The use of [[[ and ]]] is deliberated to disambiguate the parser, as
>a=20
>> frame transformation can have any C++ code. You ca see it as { }.
>>
>> We can see a frame as a program transformation, that takes nodes of=20
>> C++ BNF grammar as parameters and return a new node.
>> The parameter of the preceding frame are Id (as C++ identifiers) that
>
>> has a default value that depend on the template parameter C.
>> These Id can be used as any other identifier and the [[[ ]]]=20
>> transformation will replace them by its respective symbols. This
>works=20
>> similar to a macro.
>>
>> When we want to repeat something on variadic parameters we can use
>the=20
>> operator... on the sub-frame we want to repeat enclosed by [[[ ]]].
>>
>> What do you think?
>>
>> Best,
>> Vicente
>>
>> P.S. I'm working on other cases that would be much more complex using
>
>> template meta-programming than using this frame concept.
>>
>>
>Hi, here it is
>
>the example is related to the use case of calling a specific function=20
>before delegating.
>Given
>
>#include <delegate>
>class C {
>public:
>int i;
>void f();
>vector<int> g(double);
>private:
>void h(int);
>};
>
>The generic delegate_before_call<C,F,B> should be identical to the=20
>manual specialization below
>
>template<class F, class B>
>class delegate_before_call<C, F, B> : public B
>{
>   using this_type =3D delegate_before<C, F, B>;
>   friend F;
>public:
>   delegate_before_call(C &c, F f) : wrapped(c), fct(f) {}
>   void f() {
>     fct( ); // (1.a)
>     wrapped.f();
>   }
>   vector<int> g(double d) {
>     fct( ); // [2.a]
>     return wrapped.g(d);
>   }
>};
>
>Using the frame the solution almost as short as if we made the=20
>specialization by hand
>
>
>template<class T>
>*frame*delegate_members_before_call[
>meta::member_function ...Member =3D meta::public_function_members_of<T> >
>] -> DeclarationList
>*[[[
>   [[[
>   Member::signature*{
>     fct( );
>     return wrapped.*Member::forward_call()*;
>   }
>*  ]]]...
>]]]*
>
>template<class T, class F, class B>
>class delegate_before_call : public B
>{
>   using this_type =3D delegate_before_call<T, F, B>;
>   friend F;
>public:
>   delegate_before(C &c, F f) : wrapped(c), fct(f) {}
>*[[[ delegate_members_before_call<T>[] ]]]
>*};
>
>This is simple for the user. Maybe complex for the compiler.
>
>I have found a lot of difficulties to find a good design for solving=20
>this problem without this new frame feature.
>How to generate the definition of the new function?
>
>vector<int> g(double d) {
>     fct( );
>     return wrapped.g(d);
>   }
>
>Using lambdas?
>
>How to include these function definitions in the new class? Using an=20
>inheritance hierarchy has some troubles with the wrapped overloaded=20
>functions, as show by Boost.TypeErasure implementation?
>
>IMO, mixing code and [[[reification]]] via frames is the way to go so=20
>solve these kind of problems.
>
>I would like to see what other can propose using know template=20
>meta-programming techniques.
>
>Best,
>Vicente
>
>
>--=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 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/.

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

------TDR5S1HHS640W2VPUCPCZKBHY96PJR
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D=
"Content-Type" /><meta content=3D"text/html; charset=3DISO-8859-1" http-equ=
iv=3D"Content-Type" /><meta http-equiv=3D"content-type" content=3D"text/htm=
l;
        charset=3DISO-8859-1" /><meta http-equiv=3D"content-type" content=
=3D"text/html;
        charset=3DISO-8859-1" /><title></title><meta name=3D"GENERATOR" con=
tent=3D"OpenOffice.org 3.3 (Unix)" /><style type=3D"text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style><meta name=3D"GENERATOR" content=3D"OpenOffice.org 3.3 (Unix)" /><=
style type=3D"text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style><meta name=3D"GENERATOR" content=3D"OpenOffice.org 3.3 (Unix)" /><=
style type=3D"text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->?</style></head><body bgcolor=3D"#FFFFFF" text=3D"#000000"><p dir=3D"lt=
r">Please clarify whether "frame" and your proposed "operator [[[ ]]]" work=
 as cues for expanding code constructs that are respecting type safety / la=
nguage grammar and when should such operations take place.</p>
<p dir=3D"ltr">It seems that you are you just adroitly attempting to move f=
unction - like macro definition and invocation in a form of expansion withi=
n the definition scope of class / function templates, while giving some con=
stant expression evaluation characteristics in said operation.</p>
<p dir=3D"ltr">Should that hold, you would just be forcing tightly coupled =
evaluations to occur prior to template instantiation and even definition. H=
ave you considered where such a way would clash with templates / constexpr =
?</p>
<p dir=3D"ltr">I am just saying that by wanting to remove the need for prep=
rocessor metaprogramming with the current facilities, in the end the route =
is to augment constexpr / template metaprogramming, not introduce another p=
reprocessor.</p>
<p dir=3D"ltr">I would thus like to see where this unambiguously extends te=
mplates and constexpr and how it deals with the simple degenerate case of p=
lain text substitution and concatenation, even when the strings in question=
 are totally random (just like what happens with the preprocessor now).</p>
<p dir=3D"ltr">As for people who rely on external tools for code generation=
, I think they are simply trying to avoid current preprocessor metaprogramm=
ing techniques for some subjective disadvantage. Examples like boost's own =
use demonstrates otherwise.<br>
</p>
<br><br><div class=3D"gmail_quote">&quot;Vicente J. Botet Escriba&quot; &lt=
;vicente.botet@wanadoo.fr&gt; wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;">

 =20
   =20
 =20
 =20
    <div class=3D"moz-cite-prefix">Le 01/11/13 20:13, Vicente J. Botet
      Escriba a &eacute;crit&nbsp;:<br />
    </div>
    <blockquote cite=3D"mid:5273FD69.90406@wanadoo.fr" type=3D"cite">
     =20
      <div class=3D"moz-cite-prefix">Le 01/11/13 13:24, Stack Machine a
        &eacute;crit&nbsp;:<br />
      </div>
      <blockquote cite=3D"mid:0f593183-83f3-4aa2-881d-7837aea2c1c7@isocpp.o=
rg" type=3D"cite">
        <div dir=3D"ltr">"How does this differ from preprocessor macros?"<b=
r />
          It differs from preprocessor macros in that you can have
          control flow withing your macro. This feature is supposed to
          replace preprocessor macros completely. It can do anything
          preprocessor macros can do, except at the language level,
          better readable and it is more powerful. Not only that, I'd
          also like to get rid of external code generation tools. The
          fact that people use these tools indicates a lack of language
          features.<br />
          <br />
          I agree that strings are not ideal if used directly. The
          standard could provide utilities for generating these strings.<br=
 />
          <div class=3D"prettyprint" style=3D"background-color: rgb(250,
            250, 250); border-color: rgb(187, 187, 187); border-style:
            solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint">
              </code><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br />
                  macro generateEq</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br />
                </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color:
                  #000;" class=3D"styled-by-prettify"><br />
                  &nbsp; &nbsp; std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">meta</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">expression

                  ret </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color:
                  #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">true</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br />
                  <br />
                  &nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> mem </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">meta</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">members_of</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;())</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br />
                  &nbsp; &nbsp; &nbsp; &nbsp; ret </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:
                  #000;" class=3D"styled-by-prettify"> ret </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> fb</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">].</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">mem </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> fb</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">].</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">mem</span><span style=3D"co=
lor: #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">//
                  overloaded operators to build expressions</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br />
                  &nbsp; &nbsp; </span><br />
                <span style=3D"color: #000;" class=3D"styled-by-prettify"><=
code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-=
prettify">&nbsp;&nbsp;&nbsp; std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">meta</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">function_builder</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">bool</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)&gt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">
                      fb</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-prett=
ify">"operator

                      =3D=3D"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br />
                    </span></code>&nbsp; &nbsp; fb</span><span style=3D"col=
or:
                  #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">append</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">meta</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">return_statement</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">ret</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br />
                  &nbsp; &nbsp; inject fb</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color:
                  #000;" class=3D"styled-by-prettify">str</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br />
                </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color:
                  #000;" class=3D"styled-by-prettify"><br />
                </span></div>
            </div>
          These classes can be built on top of the basic macro system
          that uses strings.<br />
          <br />
          Maybe in this specific use case boost::fusion::fold is indeed
          better. (I wasn't aware of the existence of it.) But there are
          a lot of cases where external code generators are used and I'd
          like to get rid of the need for them.<br />
        </div>
        <br />
      </blockquote>
      <br />
      Hi,<br />
      <br />
      I have taken a similar approach with what I've called frames.
      While the example is not enough motivating this big feature, it is
      simple enough to understand the power of the feature. Instead of
      macro I have used frame and instead of inject I have used a new
      operator [[[ ]]].<br />
      As your approach, the advantage is the simplicity of the user
      interface. It allows to mix direct code and transformations using
      reflection. IMO this interface is closer to the user expectation,
      as using template meta-programming (in the general case, not this
      simple case) would be quite complex and request the compiler a
      lot, well this is what I believe, but I'm not a compiler writer.<br /=
>
      <br />
     =20
      To generate the equality operator we can use a <b>frame</b>
      template DefineOperatorEqual that will do what we expect.<br />
      <br />
      struct X {<br />
      &nbsp; int a;<br />
      &nbsp; string b;<br />
      <font color=3D"#3333ff"> &nbsp; <b>[[[</b> DefineOperatorEqual&lt;X&g=
t;
        <b>]]]</b> //or better syntax</font><br />
      };<br />
      <br />
      where <br />
      <br />
     =20
      template &lt;typename C&gt;<br />
      <font color=3D"#3333ff"><b>frame</b></font> DefineOperatorEqual<br />
      <font color=3D"#3333ff"><b>(</b></font><br />
      <font color=3D"#3333ff"><b>&nbsp;&nbsp;&nbsp; </b><b>meta::</b><b>Id_=
t ... Member
          =3D meta::data_members_name_of&lt;C&gt;()</b><b><br />
        </b><b> </b><b>) -&gt; meta::function_declaration</b><b>_t<br />
        </b><b> </b><b>[[[</b><b><br />
        </b></font>&nbsp; bool operator =3D=3D (C const&amp; lhs, C const&a=
mp;
      rhs) {<br />
      &nbsp;&nbsp;&nbsp;&nbsp; return true<br />
      &nbsp;&nbsp;&nbsp;&nbsp; <font color=3D"#3333ff"> <b>[[[</b> </font>&=
amp;&amp;
      lhs.Member =3D=3D rhs.Member <font color=3D"#3333ff"><b>]]]...</b></f=
ont><br />
      &nbsp;&nbsp;&nbsp;&nbsp; ;<br />
      &nbsp; }<br />
      <font color=3D"#3333ff"><b>]]]</b><br />
      </font><br />
      The use of [[[ and ]]] is deliberated to disambiguate the parser,
      as a frame transformation can have any C++ code. You ca see it as
      { }.<br />
      <br />
      We can see a frame as a program transformation, that takes nodes
      of C++ BNF grammar as parameters and return a new node.<br />
      The parameter of the preceding frame are Id (as C++ identifiers)
      that has a default value that depend on the template parameter C.<br =
/>
      These Id can be used as any other identifier and the [[[ ]]]
      transformation will replace them by its respective symbols. This
      works similar to a macro.<br />
      <br />
      When we want to repeat something on variadic parameters we can use
      the operator... on the sub-frame we want to repeat enclosed by [[[
      ]]].<wbr /><br />
      <br />
      What do you think?<br />
      <br />
      Best,<br />
      Vicente<br />
      <br />
      P.S. I'm working on other cases that would be much more complex
      using template meta-programming than using this frame concept.<br />
      <br />
      <br />
    </blockquote>
    <font size=3D"+1">Hi, here it is <br />
      <br />
      the example is related to the use case of calling a specific
      function before delegating.<br />
      <big><font style=3D"font-size: 9pt"><font face=3D"Times New Roman,
            serif">Given</font></font>
      </big></font>
    <p style=3D"margin-left: 1.25cm"><big><font face=3D"Courier New,
          monospace" size=3D"+1"><big><font style=3D"font-size: 9pt">#inclu=
de
              &lt;delegate&gt;<br />
              class C {<br />
              public:<br />
              int i;<br />
              void f();<br />
              vector&lt;int&gt; g(double);<br />
              private:<br />
              void h(int);<br />
              };</font></big></font></big></p>
    <big><font size=3D"+1"><big>
          <font style=3D"font-size: 9pt">The generic
            <font face=3D"Courier New, monospace">delegate_before_call&lt;C=
,F,B&gt;</font>
            should be identical to the manual specialization below</font>
        </big></font></big>
   =20
   =20
   =20
    <p style=3D"margin-left: 1.25cm"><big><font face=3D"Courier New,
          monospace" size=3D"+1"><big><font style=3D"font-size: 9pt">templa=
te&lt;class
F,
              class B&gt;<br />
              class delegate_before_call&lt;C, F, B&gt; : public
              B<br />
              {<br />
              &nbsp; using this_type =3D delegate_before&lt;C, F, B&gt;;<br=
 />
              &nbsp; friend F;<br />
              public:<br />
              &nbsp; delegate_before_call(C &amp;c, F f) :
              wrapped(c), fct(f) {}<br />
              &nbsp; void f() {<br />
              &nbsp;&nbsp;&nbsp; fct( ); // (1.a)<br />
              &nbsp;&nbsp;&nbsp; wrapped.f();<br />
              &nbsp; }<br />
              &nbsp; vector&lt;int&gt; g(double d) {<br />
              &nbsp;&nbsp;&nbsp; fct( ); // [2.a]<br />
              &nbsp;&nbsp;&nbsp; return wrapped.g(d);<br />
              &nbsp; }<br />
              };</font></big></font></big></p>
    <font size=3D"+1">
      Using the frame the solution almost as short as if we made the
      specialization by hand<br />
    </font>
   =20
   =20
   =20
    <p style=3D"margin-left: 1.25cm"><font face=3D"Courier New, monospace" =
size=3D"+1"><font style=3D"font-size: 9pt"><br />
        </font></font><font size=3D"+1"><font style=3D"font-size: 9pt"><tt>=
<big>template&lt;class
              T&gt;<br />
            </big></tt></font></font><tt><big><font size=3D"+1"><big><font =
style=3D"font-size: 9pt"><b>frame</b></font></big></font><font size=3D"+1">=
<big><font style=3D"font-size: 9pt">
                delegate_members_before_call[<br />
                meta::member_function
                ...Member =3D meta::public_function_members_of&lt;T&gt;
                &gt;<br />
                ]
                -&gt; DeclarationList<br />
              </font></big></font><font size=3D"+1"><big><font style=3D"fon=
t-size: 9pt"><b>[[[
                  <br />
                  &nbsp; [[[ <br />
                  &nbsp; Member::signature</b></font></big></font><font siz=
e=3D"+1"><big><font style=3D"font-size: 9pt">
                {<br />
                &nbsp; &nbsp; fct( </font></big></font><font size=3D"+1"><b=
ig><font style=3D"font-size: 9pt">);<br />
                &nbsp;&nbsp;&nbsp; return wrapped.</font></big></font><font=
 size=3D"+1"><big><font style=3D"font-size: 9pt"><b>Member::forward_call()<=
/b></font></big></font><font size=3D"+1"><big><font style=3D"font-size: 9pt=
">
                ;<br />
                &nbsp; }<br />
              </font></big></font><font size=3D"+1"><big><font style=3D"fon=
t-size: 9pt"><b>&nbsp; ]]]...<br />
                  ]]]</b></font></big></font></big></tt></p>
    <tt><big><font size=3D"+1"><big>
          </big></font></big></tt>
    <p style=3D"margin-left: 1.25cm"><tt><big><font size=3D"+1"><big><font =
style=3D"font-size: 9pt">template&lt;class
                T, class F, class B&gt;<br />
                class delegate_before_call : public B<br />
                {<br />
                &nbsp; using this_type =3D delegate_before_call&lt;T, F, B&=
gt;;<br />
                &nbsp; friend
                F;<br />
                public:<br />
                &nbsp; delegate_before(C &amp;c, F f) : wrapped(c),
                fct(f) {}</font><br />
              <small>&nbsp;</small><font style=3D"font-size: 8pt"><font sty=
le=3D"font-size: 9pt"><b><small>[[[
                      delegate_members_before_call&lt;T&gt;[] ]]]</small><b=
r />
                  </b></font><font style=3D"font-size: 9pt">};</font></font=
></big></font></big></tt></p>
    <font size=3D"+1">
      This is simple for the user. Maybe complex for the compiler.<br />
      <br />
      I have found a lot of difficulties to find a good design for
      solving this problem without this new frame feature.<br />
      How to generate the definition of the new function?&nbsp; <br />
      <br />
      <font face=3D"Courier New, monospace"><font style=3D"font-size: 9pt">=
<big>&nbsp;
            vector&lt;int&gt; g(double d) {<br />
            &nbsp;&nbsp;&nbsp; fct( ); <br />
            &nbsp;&nbsp;&nbsp; return wrapped.g(d);<br />
            &nbsp; }<br />
            <br />
          </big></font></font></font>
   =20
   =20
    <big><big><font style=3D"font-size: 9pt" size=3D"+2">Using
          lambdas?</font><font style=3D"font-size: 9pt" size=3D"+2"><br />
          <br />
          How to include these function definitions in the new class?
          Using an inheritance hierarchy has some troubles with the
          wrapped overloaded functions, as show by Boost.TypeErasure
          implementation?<br />
          <br />
          IMO, mixing code and [[[reification]]] via frames is the way
          to go so solve these kind of problems. <br />
          <br />
          I would like to see what other can propose using know template
          meta-programming techniques.<br />
          <br />
          Best,<br />
          Vicente</font><font style=3D"font-size: 9pt" size=3D"+2"><br />
        </font><font face=3D"Courier New, monospace"><font style=3D"font-si=
ze: 9pt" size=3D"2"><big><big><br />
                <br />
              </big></big></font></font></big></big>
 =20


<p></p>
</blockquote></div></body></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

------TDR5S1HHS640W2VPUCPCZKBHY96PJR--


.

This is a multi-part message in MIME format.
--------------000909080101080503070406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 03/11/13 01:45, George Makrydakis a =E9crit :
>
> Please clarify whether "frame" and your proposed "operator [[[ ]]]"=20
> work as cues for expanding code constructs that are respecting type=20
> safety / language grammar and
>
Yes, a frame has nodes of the language grammar as parameters and return=20
a specific grammar node.
>
> when should such operations take place.
>
Good question. I have not a response now and I have no responses to some=20
of your good questions. I have not worked the approach enough to make a=20
concrete proposal.
>
> It seems that you are you just adroitly attempting to move function -=20
> like macro definition and invocation in a form of expansion within the=20
> definition scope of class / function templates, while giving some=20
> constant expression evaluation characteristics in said operation.
>
Right.
>
> Should that hold, you would just be forcing tightly coupled=20
> evaluations to occur prior to template instantiation and even definition.
>
Why do you think this?
>
> Have you considered where such a way would clash with templates /=20
> constexpr ?
>
No, not yet. Which one do you see?.
>
> I am just saying that by wanting to remove the need for preprocessor=20
> metaprogramming with the current facilities, in the end the route is=20
> to augment constexpr / template metaprogramming, not introduce another=20
> preprocessor.
>
I don't see a frame as a preprocessor but as a term rewriting system. I=20
want to be able to

* build grammar node instances by reflection
* transform grammar nodes instances on grammar nodes instances, and
* expand the code represented by a grammar node instance by reification.

The operator [[[]]] taking as parameter some code results in a grammar node=
..
Frames transform grammar nodes on grammar nodes.
The operator [[[]]] taking as parameter a grammar node results in the=20
associated code.
Which syntax is more appropriated to support these requirements needs=20
refinement.

A grammar node instance is represented as a type on the std::meta namespace=
..
The compiler should provide some intrinsic meta-functions to obtain=20
grammar node instances from C++ types.

My approach doesn't takes the augment constexpr / template=20
metaprogramming route, and maybe the route I'm taking is a dead-end.

> I would thus like to see where this unambiguously extends templates=20
> and constexpr and how it deals with the simple degenerate case of=20
> plain text substitution and concatenation, even when the strings in=20
> question are totally random (just like what happens with the=20
> preprocessor now).
>
As I see frames, they are orthogonal to templates and constexpr. The=20
examples I gave are template frames, but we could have frames that are=20
not templates. A frame would be implicitly a constexpr as if the=20
parameters are know at compile time, the result is obtained at compile=20
time. If wewere  able to build grammar nodes at run-time, the frames=20
could be evaluated at run-time.

While at a first glance it could seem that frames are nothing more than=20
macros, their parameters are language grammar nodes. This makes a big=20
difference and IMHO it opens to more elaborated transformation techniques.

> As for people who rely on external tools for code generation, I think=20
> they are simply trying to avoid current preprocessor metaprogramming=20
> techniques for some subjective disadvantage. Examples like boost's own=20
> use demonstrates otherwise.
>
>
I have nothing against external tools, but I think this is off topic on=20
this ML as far as the generation is external.

I have used the preprocessor meta-programming techniques in TBoost.Enums=20
and  TBoost.Opaque and while this allows to experiment I would like to=20
see something more appropriated introducing reflection in the language.

Ville has suggested in [1] an approach that is more in line with the=20
current language. operator member_name when member_name is a compile=20
time string would define a new function. meta::invoke_member allows to=20
call to a function identified by a compile time string.

template <Compile_time_string member_name, class ...Args>
   decltype(auto) operator member_name(Args&&... args)
{
    fct();
    decltype(auto) ret =3D meta::invoke_member<T>(this, member_name,=20
forward<Args>(args)...);
    return ret;
}

Is like this approach as it requires less changes to the standard.

Best,
Vicente

[1]=20
https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/HsjY_3IznHc

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

--------------000909080101080503070406
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 03/11/13 01:45, George Makrydakis a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">Please clarify whether "frame" and your proposed
        "operator [[[ ]]]" work as cues for expanding code constructs
        that are respecting type safety / language grammar and </p>
    </blockquote>
    Yes, a frame has nodes of the language grammar as parameters and
    return a specific grammar node. <br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">when should such operations take place.</p>
    </blockquote>
    Good question. I have not a response now and I have no responses to
    some of your good questions. I have not worked the approach enough
    to make a concrete proposal. <br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">It seems that you are you just adroitly attempting to
        move function - like macro definition and invocation in a form
        of expansion within the definition scope of class / function
        templates, while giving some constant expression evaluation
        characteristics in said operation.</p>
    </blockquote>
    Right.<br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">Should that hold, you would just be forcing tightly
        coupled evaluations to occur prior to template instantiation and
        even definition. </p>
    </blockquote>
    Why do you think this?<br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">Have you considered where such a way would clash with
        templates / constexpr ?</p>
    </blockquote>
    No, not yet. Which one do you see?.<br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">I am just saying that by wanting to remove the need
        for preprocessor metaprogramming with the current facilities, in
        the end the route is to augment constexpr / template
        metaprogramming, not introduce another preprocessor.</p>
    </blockquote>
    I don't see a frame as a preprocessor but as a term rewriting
    system. I want to be able to <br>
    <br>
    * build grammar node instances by reflection<br>
    * transform grammar nodes instances on grammar nodes instances, and<br>
    * expand the code represented by a grammar node instance by
    reification. <br>
    <br>
    The operator [[[]]] taking as parameter some code results in a
    grammar node.<br>
    Frames transform grammar nodes on grammar nodes.<br>
    The operator [[[]]] taking as parameter a grammar node results in
    the associated code.<br>
    Which syntax is more appropriated to support these requirements
    needs refinement.<br>
    <br>
    A grammar node instance is represented as a type on the std::meta
    namespace.<br>
    The compiler should provide some intrinsic meta-functions to obtain
    grammar node instances from C++ types.<br>
    <br>
    My approach doesn't takes the augment constexpr / template
    metaprogramming route, and maybe the route I'm taking is a dead-end.<br>
    &nbsp; <br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">I would thus like to see where this unambiguously
        extends templates and constexpr and how it deals with the simple
        degenerate case of plain text substitution and concatenation,
        even when the strings in question are totally random (just like
        what happens with the preprocessor now).</p>
    </blockquote>
    <font color="#3333ff"><font color="#000000">As I see frames, they
        are orthogonal to templates and constexpr. The examples I gave
        are template frames, but we could have frames that are not
        templates. A frame would be implicitly a constexpr as if the
        parameters are know at compile time, the result is obtained at
        compile time. If wewere&nbsp; able to build grammar nodes at
        run-time, the frames could be evaluated at run-time.<br>
        <br>
        While at a first glance it could seem that frames are nothing
        more than macros, their parameters are language grammar nodes.
        This makes a big difference and IMHO it opens to more elaborated
        transformation techniques.</font><br>
    </font><br>
    <blockquote
      cite="mid:afa93a4b-5be0-4d4b-b482-c1e0a442e9c0@email.android.com"
      type="cite">
      <p dir="ltr">As for people who rely on external tools for code
        generation, I think they are simply trying to avoid current
        preprocessor metaprogramming techniques for some subjective
        disadvantage. Examples like boost's own use demonstrates
        otherwise.<br>
      </p>
      <br>
    </blockquote>
    I have nothing against external tools, but I think this is off topic
    on this ML as far as the generation is external.<br>
    <br>
    I have used the preprocessor meta-programming techniques in
    TBoost.Enums and&nbsp; TBoost.Opaque and while this allows to experiment
    I would like to see something more appropriated introducing
    reflection in the language.<br>
    <br>
    Ville has suggested in [1] an approach that is more in line with the
    current language. operator member_name when member_name is a compile
    time string would define a new function. meta::invoke_member allows
    to call to a function identified by a compile time string.<br>
    <br>
    <div>template &lt;Compile_time_string member_name, class ...Args&gt;
      <br>
      &nbsp; decltype(auto) operator member_name(Args&amp;&amp;... args)<br>
      {<br>
    </div>
    <div>&nbsp;&nbsp; fct();<br>
    </div>
    <div>&nbsp;&nbsp; decltype(auto) ret = meta::invoke_member&lt;T&gt;(this,
      member_name, forward&lt;Args&gt;(args)...);<br>
    </div>
    &nbsp;&nbsp; return ret;<br>
    <div>}</div>
    <br>
    Is like this approach as it requires less changes to the standard.<br>
    <br>
    Best,<br>
    Vicente<br>
    <br>
    [1]
    <a class="moz-txt-link-freetext"
href="https://groups.google.com/a/isocpp.org/forum/#%21topic/reflection/HsjY_3IznHc">https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/HsjY_3IznHc</a>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------000909080101080503070406--

.

--047d7b15afd5083a8e04eaed22e7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 6, 2013 at 1:56 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

>  Le 03/11/13 01:45, George Makrydakis a =E9crit :
>
> Please clarify whether "frame" and your proposed "operator [[[ ]]]" work
> as cues for expanding code constructs that are respecting type safety /
> language grammar and
>
> Yes, a frame has nodes of the language grammar as parameters and return a
> specific grammar node.
>
> when should such operations take place.
>
> Good question. I have not a response now and I have no responses to some
> of your good questions. I have not worked the approach enough to make a
> concrete proposal.
>

First of all, you will have to excuse my delayed reply, it was due to my
own limited availability. Make a note of this reply of yours here because I
will be using it later on.

>  It seems that you are you just adroitly attempting to move function -
> like macro definition and invocation in a form of expansion within the
> definition scope of class / function templates, while giving some constan=
t
> expression evaluation characteristics in said operation.
>
> Right.
>
> Should that hold, you would just be forcing tightly coupled evaluations t=
o
> occur prior to template instantiation and even definition.
>
> Why do you think this?
>

Imagine wanting to repetitively create a series of repetitive constructs
within a given function / class template definition, where each item is
derived from a series of numbers within the [0,N] range where N is any
positive integer. Notice that in order for such a template definition to
occur, all the syntactically valid constructs within definition scope would
have to be present. Since we are talking about systematically generating
these at the level of a "preprocessor substitute" (as in your concept), we
would have to have a way to control such expansion, some sort of flow
control. Such control means having expression evaluation implemented in
some form. A prime example of hijacking concatenation into creating such
"expression evaluation" mechanics are the internals of boost libraries,
where boost.preprocessor is used. *Take note that this is very well defined
as to where and when everything takes place: this is "text" generation in
the end, prior to any action on behalf of the compiler.*

I think that the need for such a solution could be done away with if the
templates / constexpr system were extended properly. I do not have myself a
complete solution on this, but as everyone on the grounds of this mailing
list I just have a few ideas about the "dont's" and some few pretty
concrete directions as to the "do's". It would take me quite a while to
explain the reasons about them and eventually I will. One aspect is
actually modifying parameter expansion pack semantics. More on that later
on.


>  Have you considered where such a way would clash with templates /
> constexpr ?
>
> No, not yet. Which one do you see?.
>

The one I described above. It is introducing another system for what
templates / constexpr should be allowed to do (with a few expansions to
their semantics). In a way, through parameter unpacking, templates have
already acquired a way to expand type - dependent (and safe) constructs for
any given number of type / non type / template template type parameters
used. This is the consequence of introducing variadicity in template
parameters. In the C++11 standard, 14.5.3 has several examples for your
enjoyment. You can also watch Andrei Alexandrescu's excellent talk about
variadic templates being "funadic" at
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Templ=
ates-are-Funadic.
There are several ways to do different things with parameter pack
expansion, even more than several when it comes to multiple parameter
packs. I am just citing one of Alexandrescu's examples:

*template* <*class*... Ts> void fun( Ts... vs ) {
    gun( A<Ts...>::hun(vs)...);
    gun( A<Ts...>::hun(vs...));
    gun( A<Ts>::hun(vs)...);
}

This is not the most complicated thing you will see in parameter pack
expansion but it kind of foreshadows how one can deploy extensions to
unpacking patterns to cover for a few more scenarios where more complicated
constructs are required (no, you can't do it with unpacking as it is with
C++11, C++14). I reserve the right to explain this further in a future post
all for just that (hopefully). It is not an easy sight and it would require
some additional syntax to make things unambiguous because (...) is not
enough.


>  I am just saying that by wanting to remove the need for preprocessor
> metaprogramming with the current facilities, in the end the route is to
> augment constexpr / template metaprogramming, not introduce another
> preprocessor.
>
> I don't see a frame as a preprocessor but as a term rewriting system. I
> want to be able to
>
> * build grammar node instances by reflection
> * transform grammar nodes instances on grammar nodes instances, and
> * expand the code represented by a grammar node instance by reification.
>
> The operator [[[]]] taking as parameter some code results in a grammar
> node.
> Frames transform grammar nodes on grammar nodes.
> The operator [[[]]] taking as parameter a grammar node results in the
> associated code.
> Which syntax is more appropriated to support these requirements needs
> refinement.
>
> A grammar node instance is represented as a type on the std::meta
> namespace.
> The compiler should provide some intrinsic meta-functions to obtain
> grammar node instances from C++ types.
>
> My approach doesn't takes the augment constexpr / template metaprogrammin=
g
> route, and maybe the route I'm taking is a dead-end.
>
As I see frames, they are orthogonal to templates and constexpr. The
> examples I gave are template frames, but we could have frames that are no=
t
> templates. A frame would be implicitly a constexpr as if the parameters a=
re
> know at compile time, the result is obtained at compile time. If wewere
> able to build grammar nodes at run-time, the frames could be evaluated at
> run-time.
>

> While at a first glance it could seem that frames are nothing more than
> macros, their parameters are language grammar nodes. This makes a big
> difference and IMHO it opens to more elaborated transformation techniques=
..
>

I would not say that it is a dead - end, but I think it needs more work
when it comes to clarifying semantics and where operations should take
place in relation i.e. to template definition, declaration and
instantiation. But you are not at the same problem domain as the
preprocessor right now, so you can't substitute it as you wish. Frames (as
you are proposing them at least) are not exactly analogous to AST term
rewriting macros (see Nimrod's http://nimrod-code.org/) either. Because of
the (for the time being!) ambiguous semantics you propose, they clash with
established systems as templates and constexpr. Think again about why I
asked as to when and where frame operations should take place. This is more
important than it seems.


>
>  As for people who rely on external tools for code generation, I think
> they are simply trying to avoid current preprocessor metaprogramming
> techniques for some subjective disadvantage. Examples like boost's own us=
e
> demonstrates otherwise.
>
>  I have nothing against external tools, but I think this is off topic on
> this ML as far as the generation is external.
>

I did not understand your reply here. As I said, the preprocessor is fairly
adequate if used properly; however it does require some inner knowledge of
the techniques involved when doing metaprogramming with it and awareness of
the necessary compromises in designing solutions with it. People not
particularly eager to gain that knowledge, turn to external tools. Would I
like to have something better? Of course I would, but if the preprocessor
is all I am given within C++, then I must be ready to make the best use of
it. And I have no problems with that either.


>
> I have used the preprocessor meta-programming techniques in TBoost.Enums
> and  TBoost.Opaque and while this allows to experiment I would like to se=
e
> something more appropriated introducing reflection in the language.
>
> Ville has suggested in [1] an approach that is more in line with the
> current language. operator member_name when member_name is a compile time
> string would define a new function. meta::invoke_member allows to call to=
 a
> function identified by a compile time string.
>

I am aware of Ville Voutilainen's approaches to problems like this and I am
quite a fan of his solutions when it comes to them. But we are going to
reflection now, which would derail the entire thread into something
different. Systematic generation of valid C++ constructs for reducing hand
- written constructs is not something closely related to reflection but as
a "workaround" for the lack of said feature at the language level. It is
obviously that in the end, you are actually trying to solve a compile / run
- time barrier problem, hence your interest in reflection. Try thinking of
the "frames" you are proposing as something that should not however just
exist to help reflection purposes.


>
>
> [1]
> https://groups.google.com/a/isocpp.org/forum/#!topic/reflection/HsjY_3Izn=
Hc
>

Really enjoyed your posts of course, sorry for the delayed reply!

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

--047d7b15afd5083a8e04eaed22e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra">On Wed, Nov 6, 2013 at 1:56=
 PM, Vicente J. Botet Escriba <span dir=3D"ltr">&lt;<a href=3D"mailto:vicen=
te.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>&gt;</sp=
an> wrote:<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div>Le 03/11/13 01:45, George Makrydakis a
      =E9crit=A0:<br>
    </div><div class=3D"im">
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Please clarify whether &quot;frame&quot; and your prop=
osed
        &quot;operator [[[ ]]]&quot; work as cues for expanding code constr=
ucts
        that are respecting type safety / language grammar and </p>
    </blockquote></div>
    Yes, a frame has nodes of the language grammar as parameters and
    return a specific grammar node. <br><div class=3D"im">
    <blockquote type=3D"cite">
      <p dir=3D"ltr">when should such operations take place.</p>
    </blockquote></div>
    Good question. I have not a response now and I have no responses to
    some of your good questions. I have not worked the approach enough
    to make a concrete proposal.<br></div></blockquote><div><br></div><div>=
First of all, you will have to excuse my delayed reply, it was due to my ow=
n limited availability. Make a note of this reply of yours here because I w=
ill be using it later on.<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div text=3D"#00000=
0" bgcolor=3D"#FFFFFF"><div class=3D"im">
    <blockquote type=3D"cite">
      <p dir=3D"ltr">It seems that you are you just adroitly attempting to
        move function - like macro definition and invocation in a form
        of expansion within the definition scope of class / function
        templates, while giving some constant expression evaluation
        characteristics in said operation.</p>
    </blockquote></div>
    Right.<br>
    <div class=3D"im"><blockquote type=3D"cite">
      <p dir=3D"ltr">Should that hold, you would just be forcing tightly
        coupled evaluations to occur prior to template instantiation and
        even definition. </p>
    </blockquote></div>
    Why do you think this?</div></blockquote><br></div><div class=3D"gmail_=
quote">Imagine wanting to repetitively create a series of repetitive constr=
ucts within a given function / class template definition, where each item i=
s derived from a series of numbers within the [0,N] range where N is any po=
sitive integer. Notice that in order for such a template definition to occu=
r, all the syntactically valid constructs within definition scope would hav=
e to be present. Since we are talking about systematically generating these=
 at the level of a &quot;preprocessor substitute&quot; (as in your concept)=
, we would have to have a way to control such expansion, some sort of flow =
control. Such control means having expression evaluation implemented in som=
e form. A prime example of hijacking concatenation into creating such &quot=
;expression evaluation&quot; mechanics are the internals of boost libraries=
, where boost.preprocessor is used. <b>Take note that this is very well def=
ined as to where and when everything takes=20
place: this is &quot;text&quot; generation in the end, prior to any action =
on=20
behalf of the compiler.</b><br><br>I think that the need for such a solutio=
n could be done away with if the templates / constexpr system were extended=
 properly. I do not have myself a complete solution on this, but as everyon=
e on the grounds of this mailing list I just have a few ideas about the &qu=
ot;dont&#39;s&quot; and some few pretty concrete directions as to the &quot=
;do&#39;s&quot;. It would take me quite a while to explain the reasons abou=
t them and eventually I will. One aspect is actually modifying parameter ex=
pansion pack semantics. More on that later on.<br>
<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"im"><br=
>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Have you considered where such a way would clash with
        templates / constexpr ?</p>
    </blockquote></div>
    No, not yet. Which one do you see?.</div></blockquote><div><br></div><d=
iv>The one I described above. It is introducing another system for what tem=
plates / constexpr should be allowed to do (with a few expansions to their =
semantics). In a way, through parameter unpacking, templates have already a=
cquired a way to expand type - dependent (and safe) constructs for any give=
n number of type / non type / template template type parameters used. This =
is the consequence of introducing variadicity in template parameters. In th=
e C++11 standard, 14.5.3 has several examples for your enjoyment. You can a=
lso watch Andrei Alexandrescu&#39;s excellent talk about variadic templates=
 being &quot;funadic&quot; at <a href=3D"http://channel9.msdn.com/Events/Go=
ingNative/GoingNative-2012/Variadic-Templates-are-Funadic">http://channel9.=
msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Templates-are-Funadic=
</a>. There are several ways to do different things with parameter pack exp=
ansion, even more than several when it comes to multiple parameter packs. I=
 am just citing one of Alexandrescu&#39;s examples:<br>
<br><pre style=3D"color:rgb(31,28,27);background-color:rgb(255,255,255)"><b=
>template</b> &lt;<b>class</b>... Ts&gt; <span style=3D"color:rgb(0,87,174)=
">void</span> fun( Ts... vs ) {
    gun( A&lt;Ts...&gt;::hun(vs)...);
    gun( A&lt;Ts...&gt;::hun(vs...));
    gun( A&lt;Ts&gt;::hun(vs)...);
}</pre>This is not the most complicated thing you will see in parameter pac=
k expansion but it kind of foreshadows how one can deploy extensions to unp=
acking patterns to cover for a few more scenarios where more complicated co=
nstructs are required (no, you can&#39;t do it with unpacking as it is with=
 C++11, C++14). I reserve the right to explain this further in a future pos=
t all for just that (hopefully). It is not an easy sight and it would requi=
re some additional syntax to make things unambiguous because (...) is not e=
nough.<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 text=3D"#000000" bgcolor=3D"#FFFFFF"><div class=3D"im"><br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">I am just saying that by wanting to remove the need
        for preprocessor metaprogramming with the current facilities, in
        the end the route is to augment constexpr / template
        metaprogramming, not introduce another preprocessor.</p>
    </blockquote></div>
    I don&#39;t see a frame as a preprocessor but as a term rewriting
    system. I want to be able to <br>
    <br>
    * build grammar node instances by reflection<br>
    * transform grammar nodes instances on grammar nodes instances, and<br>
    * expand the code represented by a grammar node instance by
    reification. <br>
    <br>
    The operator [[[]]] taking as parameter some code results in a
    grammar node.<br>
    Frames transform grammar nodes on grammar nodes.<br>
    The operator [[[]]] taking as parameter a grammar node results in
    the associated code.<br>
    Which syntax is more appropriated to support these requirements
    needs refinement.<br>
    <br>
    A grammar node instance is represented as a type on the std::meta
    namespace.<br>
    The compiler should provide some intrinsic meta-functions to obtain
    grammar node instances from C++ types.<br>
    <br>
    My approach doesn&#39;t takes the augment constexpr / template
    metaprogramming route, and maybe the route I&#39;m taking is a dead-end=
..</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
text=3D"#000000" bgcolor=3D"#FFFFFF">
<font color=3D"#3333ff"><font color=3D"#000000">As I see frames, they
        are orthogonal to templates and constexpr. The examples I gave
        are template frames, but we could have frames that are not
        templates. A frame would be implicitly a constexpr as if the
        parameters are know at compile time, the result is obtained at
        compile time. If wewere=A0 able to build grammar nodes at
        run-time, the frames could be evaluated at run-time.<br></font></fo=
nt></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v text=3D"#000000" bgcolor=3D"#FFFFFF">
<font color=3D"#3333ff"><font color=3D"#000000">
        <br>
        While at a first glance it could seem that frames are nothing
        more than macros, their parameters are language grammar nodes.
        This makes a big difference and IMHO it opens to more elaborated
        transformation techniques.</font><br></font></div></blockquote><div=
><br>I would not say that it is a dead - end, but I think it needs more=20
work when it comes to clarifying semantics and where operations should=20
take place in relation i.e. to template definition, declaration and=20
instantiation. But you are not at the same problem domain as the=20
preprocessor right now, so you can&#39;t substitute it as you wish. Frames =
(as you are proposing them at least) are not exactly analogous to AST term =
rewriting macros (see Nimrod&#39;s <a href=3D"http://nimrod-code.org/">http=
://nimrod-code.org/</a>) either. Because of the (for the time being!) ambig=
uous semantics you propose, they clash with established systems as template=
s and constexpr. Think again about why I asked as to when and where frame o=
perations should take place. This is more important than it seems.<br>
</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div text=3D"#000000" bgcolor=3D"#FFFFFF"><font color=3D"#3333ff">
    </font><div class=3D"im"><br>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">As for people who rely on external tools for code
        generation, I think they are simply trying to avoid current
        preprocessor metaprogramming techniques for some subjective
        disadvantage. Examples like boost&#39;s own use demonstrates
        otherwise.<br>
      </p>
      <br>
    </blockquote></div>
    I have nothing against external tools, but I think this is off topic
    on this ML as far as the generation is external.<br></div></blockquote>=
<div><br></div><div>I did not understand your reply here. As I said, the pr=
eprocessor is fairly adequate if used properly; however it does require som=
e inner knowledge of the techniques involved when doing metaprogramming wit=
h it and awareness of the necessary compromises in designing solutions with=
 it. People not particularly eager to gain that knowledge, turn to external=
 tools. Would I like to have something better? Of course I would, but if th=
e preprocessor is all I am given within C++, then I must be ready to make t=
he best use of it. And I have no problems with that either.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    I have used the preprocessor meta-programming techniques in
    TBoost.Enums and=A0 TBoost.Opaque and while this allows to experiment
    I would like to see something more appropriated introducing
    reflection in the language.<br>
    <br>
    Ville has suggested in [1] an approach that is more in line with the
    current language. operator member_name when member_name is a compile
    time string would define a new function. meta::invoke_member allows
    to call to a function identified by a compile time string.<br></div></b=
lockquote><div><br></div><div>I am aware of <span class=3D""><span style=3D=
"color:rgb(34,34,34)" class=3D"">Ville Voutilainen&#39;s approaches to prob=
lems like this and I am quite a fan of his solutions when it comes to them.=
 But we are going to reflection now, which would derail the entire thread i=
nto something different. Systematic generation of valid C++ constructs for =
reducing hand - written constructs is not something closely related to refl=
ection but as a &quot;workaround&quot; for the lack of said feature at the =
language level. It is obviously that in the end, you are actually trying to=
 solve a compile / run - time barrier problem, hence your interest in refle=
ction. Try thinking of the &quot;frames&quot; you are proposing as somethin=
g that should not however just exist to help reflection purposes.<br>
</span></span></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    <br>
    [1]
    <a href=3D"https://groups.google.com/a/isocpp.org/forum/#%21topic/refle=
ction/HsjY_3IznHc" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/forum/#!topic/reflection/HsjY_3IznHc</a>
  </div></blockquote></div><br></div><div class=3D"gmail_extra">Really enjo=
yed your posts of course, sorry for the delayed reply!<br></div><div class=
=3D"gmail_extra"><br>George<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b15afd5083a8e04eaed22e7--

.

This is a multi-part message in MIME format.
--------------040309030807080203020606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 11/11/13 22:08, George Makrydakis a =E9crit :
>
> On Wed, Nov 6, 2013 at 1:56 PM, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>     Le 03/11/13 01:45, George Makrydakis a =E9crit :
>>
>>     Please clarify whether "frame" and your proposed "operator [[[
>>     ]]]" work as cues for expanding code constructs that are
>>     respecting type safety / language grammar and
>>
>     Yes, a frame has nodes of the language grammar as parameters and
>     return a specific grammar node.
>>
>>     when should such operations take place.
>>
>     Good question. I have not a response now and I have no responses
>     to some of your good questions. I have not worked the approach
>     enough to make a concrete proposal.
>
>
> First of all, you will have to excuse my delayed reply, it was due to=20
> my own limited availability. Make a note of this reply of yours here=20
> because I will be using it later on.
>
>>     It seems that you are you just adroitly attempting to move
>>     function - like macro definition and invocation in a form of
>>     expansion within the definition scope of class / function
>>     templates, while giving some constant expression evaluation
>>     characteristics in said operation.
>>
>     Right.
>>
>>     Should that hold, you would just be forcing tightly coupled
>>     evaluations to occur prior to template instantiation and even
>>     definition.
>>
>     Why do you think this?
>
>
> Imagine wanting to repetitively create a series of repetitive=20
> constructs within a given function / class template definition, where=20
> each item is derived from a series of numbers within the [0,N] range=20
> where N is any positive integer. Notice that in order for such a=20
> template definition to occur, all the syntactically valid constructs=20
> within definition scope would have to be present. Since we are talking=20
> about systematically generating these at the level of a "preprocessor=20
> substitute" (as in your concept), we would have to have a way to=20
> control such expansion, some sort of flow control. Such control means=20
> having expression evaluation implemented in some form. A prime example=20
> of hijacking concatenation into creating such "expression evaluation"=20
> mechanics are the internals of boost libraries, where=20
> boost.preprocessor is used. *Take note that this is very well defined=20
> as to where and when everything takes place: this is "text" generation=20
> in the end, prior to any action on behalf of the compiler.*
>
The single way to control expansions I have identified so far and=20
proposed in this post is the operator [[[]]]...
Maybe it is not enough. I need to admit that this is just an idea and=20
that there are a lot of undefined things.
> I think that the need for such a solution could be done away with if=20
> the templates / constexpr system were extended properly. I do not have=20
> myself a complete solution on this, but as everyone on the grounds of=20
> this mailing list I just have a few ideas about the "dont's" and some=20
> few pretty concrete directions as to the "do's". It would take me=20
> quite a while to explain the reasons about them and eventually I will.=20
> One aspect is actually modifying parameter expansion pack semantics.=20
> More on that later on.
>
My guess is that a *well defined* frame concept could help a lot. Of=20
course, if we can solve a problem with the current standard or doing=20
some alternative modification I don't insists in this frame concept, as=20
I have not analyzed all the implications.
>
>
>>     Have you considered where such a way would clash with templates /
>>     constexpr ?
>>
>     No, not yet. Which one do you see?.
>
>
> The one I described above. It is introducing another system for what=20
> templates / constexpr should be allowed to do (with a few expansions=20
> to their semantics). In a way, through parameter unpacking, templates=20
> have already acquired a way to expand type - dependent (and safe)=20
> constructs for any given number of type / non type / template template=20
> type parameters used. This is the consequence of introducing=20
> variadicity in template parameters.
Templates accepts only types and builtin types as template parameters. I=20
would like to be able to have any part of the language as template=20
parameters. As you see this is just a wish.
> In the C++11 standard, 14.5.3 has several examples for your enjoyment.=20
> You can also watch Andrei Alexandrescu's excellent talk about variadic=20
> templates being "funadic" at=20
> http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Tem=
plates-are-Funadic.=20
> There are several ways to do different things with parameter pack=20
> expansion, even more than several when it comes to multiple parameter=20
> packs. I am just citing one of Alexandrescu's examples:
>
> *template*  <*class*... Ts>void  fun( Ts... vs ) {
>      gun( A<Ts...>::hun(vs)...);
>      gun( A<Ts...>::hun(vs...));
>      gun( A<Ts>::hun(vs)...);
> }
I watched it some months ago.  It is a good think you have pointed to=20
this link. I have watched it again and I understand now the=20
complexity/ambiguity of my idea.
> This is not the most complicated thing you will see in parameter pack=20
> expansion but it kind of foreshadows how one can deploy extensions to=20
> unpacking patterns to cover for a few more scenarios where more=20
> complicated constructs are required (no, you can't do it with=20
> unpacking as it is with C++11, C++14). I reserve the right to explain=20
> this further in a future post all for just that (hopefully). It is not=20
> an easy sight and it would require some additional syntax to make=20
> things unambiguous because (...) is not enough.
I agree with you that this is not simple, even the opposite.
>
>
>>     I am just saying that by wanting to remove the need for
>>     preprocessor metaprogramming with the current facilities, in the
>>     end the route is to augment constexpr / template metaprogramming,
>>     not introduce another preprocessor.
>>
>     I don't see a frame as a preprocessor but as a term rewriting
>     system. I want to be able to
>
>     * build grammar node instances by reflection
>     * transform grammar nodes instances on grammar nodes instances, and
>     * expand the code represented by a grammar node instance by
>     reification.
>
>     The operator [[[]]] taking as parameter some code results in a
>     grammar node.
>     Frames transform grammar nodes on grammar nodes.
>     The operator [[[]]] taking as parameter a grammar node results in
>     the associated code.
>     Which syntax is more appropriated to support these requirements
>     needs refinement.
>
>     A grammar node instance is represented as a type on the std::meta
>     namespace.
>     The compiler should provide some intrinsic meta-functions to
>     obtain grammar node instances from C++ types.
>
>     My approach doesn't takes the augment constexpr / template
>     metaprogramming route, and maybe the route I'm taking is a dead-end.
>
>     As I see frames, they are orthogonal to templates and constexpr.
>     The examples I gave are template frames, but we could have frames
>     that are not templates. A frame would be implicitly a constexpr as
>     if the parameters are know at compile time, the result is obtained
>     at compile time. If wewere  able to build grammar nodes at
>     run-time, the frames could be evaluated at run-time.
>
>
>     While at a first glance it could seem that frames are nothing more
>     than macros, their parameters are language grammar nodes. This
>     makes a big difference and IMHO it opens to more elaborated
>     transformation techniques.
>
>
> I would not say that it is a dead - end, but I think it needs more=20
> work when it comes to clarifying semantics and where operations should=20
> take place in relation i.e. to template definition, declaration and=20
> instantiation.
Agreed.
> But you are not at the same problem domain as the preprocessor right=20
> now, so you can't substitute it as you wish. Frames (as you are=20
> proposing them at least) are not exactly analogous to AST term=20
> rewriting macros (see Nimrod's http://nimrod-code.org/) either.
This is quite close to what I'm looking for,even if the syntax is=20
completely different and IIUC it is limited to expressions and=20
statements. I would to be able to define any transformation inside the=20
language.
Thanks for the pointer, if you have other like this one please send me them=
..

> Because of the (for the time being!) ambiguous semantics you propose,=20
> they clash with established systems as templates and constexpr. Think=20
> again about why I asked as to when and where frame operations should=20
> take place. This is more important than it seems.
I understand your concern better now and unfortunately I have not taken=20
enough time to be able do a deeper analysis to give you some answers :(
>
>
>>     As for people who rely on external tools for code generation, I
>>     think they are simply trying to avoid current preprocessor
>>     metaprogramming techniques for some subjective disadvantage.
>>     Examples like boost's own use demonstrates otherwise.
>>
>>
>     I have nothing against external tools, but I think this is off
>     topic on this ML as far as the generation is external.
>
>
> I did not understand your reply here.
What I meant is that I didn't wanted to discuss anything related to=20
external tools.
> As I said, the preprocessor is fairly adequate if used properly;=20
> however it does require some inner knowledge of the techniques=20
> involved when doing metaprogramming with it and awareness of the=20
> necessary compromises in designing solutions with it. People not=20
> particularly eager to gain that knowledge, turn to external tools.=20
> Would I like to have something better? Of course I would, but if the=20
> preprocessor is all I am given within C++, then I must be ready to=20
> make the best use of it. And I have no problems with that either.
Neither me.
>
>
>     I have used the preprocessor meta-programming techniques in
>     TBoost.Enums and  TBoost.Opaque and while this allows to
>     experiment I would like to see something more appropriated
>     introducing reflection in the language.
>
>     Ville has suggested in [1] an approach that is more in line with
>     the current language. operator member_name when member_name is a
>     compile time string would define a new function.
>     meta::invoke_member allows to call to a function identified by a
>     compile time string.
>
>
> I am aware of Ville Voutilainen's approaches to problems like this and=20
> I am quite a fan of his solutions when it comes to them. But we are=20
> going to reflection now, which would derail the entire thread into=20
> something different. Systematic generation of valid C++ constructs for=20
> reducing hand - written constructs is not something closely related to=20
> reflection but as a "workaround" for the lack of said feature at the=20
> language level. It is obviously that in the end, you are actually=20
> trying to solve a compile / run - time barrier problem, hence your=20
> interest in reflection. Try thinking of the "frames" you are proposing=20
> as something that should not however just exist to help reflection=20
> purposes.
I'm  just trying to explore the use cases as described in N3814 Call for=20
Compile-Time Reflection Proposals and
N3492 - Use Cases for Compile-Time Reflection (Rev. 2).

I'll stop the frame concept thread here until I have something more=20
concrete. Thanks for showing me that ideas can be good, but concrete=20
proposal are much better.

Apologies if I made you lost your time,
Vicente

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

--------------040309030807080203020606
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 11/11/13 22:08, George Makrydakis a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">On Wed, Nov 6, 2013 at 1:56 PM, Vicente
          J. Botet Escriba <span dir="ltr">&lt;<a
              moz-do-not-send="true"
              href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>&gt;</span>
          wrote:<br>
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div>Le 03/11/13 01:45, George Makrydakis a &eacute;crit&nbsp;:<br>
                </div>
                <div class="im">
                  <blockquote type="cite">
                    <p dir="ltr">Please clarify whether "frame" and your
                      proposed "operator [[[ ]]]" work as cues for
                      expanding code constructs that are respecting type
                      safety / language grammar and </p>
                  </blockquote>
                </div>
                Yes, a frame has nodes of the language grammar as
                parameters and return a specific grammar node. <br>
                <div class="im">
                  <blockquote type="cite">
                    <p dir="ltr">when should such operations take place.</p>
                  </blockquote>
                </div>
                Good question. I have not a response now and I have no
                responses to some of your good questions. I have not
                worked the approach enough to make a concrete proposal.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>First of all, you will have to excuse my delayed reply,
              it was due to my own limited availability. Make a note of
              this reply of yours here because I will be using it later
              on.<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div class="im">
                  <blockquote type="cite">
                    <p dir="ltr">It seems that you are you just adroitly
                      attempting to move function - like macro
                      definition and invocation in a form of expansion
                      within the definition scope of class / function
                      templates, while giving some constant expression
                      evaluation characteristics in said operation.</p>
                  </blockquote>
                </div>
                Right.<br>
                <div class="im">
                  <blockquote type="cite">
                    <p dir="ltr">Should that hold, you would just be
                      forcing tightly coupled evaluations to occur prior
                      to template instantiation and even definition. </p>
                  </blockquote>
                </div>
                Why do you think this?</div>
            </blockquote>
            <br>
          </div>
          <div class="gmail_quote">Imagine wanting to repetitively
            create a series of repetitive constructs within a given
            function / class template definition, where each item is
            derived from a series of numbers within the [0,N] range
            where N is any positive integer. Notice that in order for
            such a template definition to occur, all the syntactically
            valid constructs within definition scope would have to be
            present. Since we are talking about systematically
            generating these at the level of a "preprocessor substitute"
            (as in your concept), we would have to have a way to control
            such expansion, some sort of flow control. Such control
            means having expression evaluation implemented in some form.
            A prime example of hijacking concatenation into creating
            such "expression evaluation" mechanics are the internals of
            boost libraries, where boost.preprocessor is used. <b>Take
              note that this is very well defined as to where and when
              everything takes place: this is "text" generation in the
              end, prior to any action on behalf of the compiler.</b><br>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    The single way to control expansions I have identified so far and
    proposed in this post is the operator [[[]]]... <br>
    Maybe it is not enough. I need to admit that this is just an idea
    and that there are a lot of undefined things.<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">I think that the need for such a
            solution could be done away with if the templates /
            constexpr system were extended properly. I do not have
            myself a complete solution on this, but as everyone on the
            grounds of this mailing list I just have a few ideas about
            the "dont's" and some few pretty concrete directions as to
            the "do's". It would take me quite a while to explain the
            reasons about them and eventually I will. One aspect is
            actually modifying parameter expansion pack semantics. More
            on that later on.<br>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    My guess is that a *well defined* frame concept could help a lot. Of
    course, if we can solve a problem with the current standard or doing
    some alternative modification I don't insists in this frame concept,
    as I have not analyzed all the implications. <br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div class="im"><br>
                  <blockquote type="cite">
                    <p dir="ltr">Have you considered where such a way
                      would clash with templates / constexpr ?</p>
                  </blockquote>
                </div>
                No, not yet. Which one do you see?.</div>
            </blockquote>
            <div><br>
            </div>
            <div>The one I described above. It is introducing another
              system for what templates / constexpr should be allowed to
              do (with a few expansions to their semantics). In a way,
              through parameter unpacking, templates have already
              acquired a way to expand type - dependent (and safe)
              constructs for any given number of type / non type /
              template template type parameters used. This is the
              consequence of introducing variadicity in template
              parameters. </div>
          </div>
        </div>
      </div>
    </blockquote>
    Templates accepts only types and builtin types as template
    parameters. I would like to be able to have any part of the language
    as template parameters. As you see this is just a wish.&nbsp; <br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>In the C++11 standard, 14.5.3 has several examples for
              your enjoyment. You can also watch Andrei Alexandrescu's
              excellent talk about variadic templates being "funadic" at
              <a moz-do-not-send="true"
href="http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Templates-are-Funadic">http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Templates-are-Funadic</a>.
              There are several ways to do different things with
              parameter pack expansion, even more than several when it
              comes to multiple parameter packs. I am just citing one of
              Alexandrescu's examples:<br>
              <br>
              <pre style="color:rgb(31,28,27);background-color:rgb(255,255,255)"><b>template</b> &lt;<b>class</b>... Ts&gt; <span style="color:rgb(0,87,174)">void</span> fun( Ts... vs ) {
    gun( A&lt;Ts...&gt;::hun(vs)...);
    gun( A&lt;Ts...&gt;::hun(vs...));
    gun( A&lt;Ts&gt;::hun(vs)...);
}</pre>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I watched it some months ago.&nbsp; It is a good think you have pointed
    to this link. I have watched it again and I understand now the
    complexity/ambiguity of my idea.<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>This is not the most complicated thing you will see in
              parameter pack expansion but it kind of foreshadows how
              one can deploy extensions to unpacking patterns to cover
              for a few more scenarios where more complicated constructs
              are required (no, you can't do it with unpacking as it is
              with C++11, C++14). I reserve the right to explain this
              further in a future post all for just that (hopefully). It
              is not an easy sight and it would require some additional
              syntax to make things unambiguous because (...) is not
              enough.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I agree with you that this is not simple, even the opposite.<big><big><br>
      </big></big>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><big><big>
                </big></big></div>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div class="im"><br>
                  <blockquote type="cite">
                    <p dir="ltr">I am just saying that by wanting to
                      remove the need for preprocessor metaprogramming
                      with the current facilities, in the end the route
                      is to augment constexpr / template
                      metaprogramming, not introduce another
                      preprocessor.</p>
                  </blockquote>
                </div>
                I don't see a frame as a preprocessor but as a term
                rewriting system. I want to be able to <br>
                <br>
                * build grammar node instances by reflection<br>
                * transform grammar nodes instances on grammar nodes
                instances, and<br>
                * expand the code represented by a grammar node instance
                by reification. <br>
                <br>
                The operator [[[]]] taking as parameter some code
                results in a grammar node.<br>
                Frames transform grammar nodes on grammar nodes.<br>
                The operator [[[]]] taking as parameter a grammar node
                results in the associated code.<br>
                Which syntax is more appropriated to support these
                requirements needs refinement.<br>
                <br>
                A grammar node instance is represented as a type on the
                std::meta namespace.<br>
                The compiler should provide some intrinsic
                meta-functions to obtain grammar node instances from C++
                types.<br>
                <br>
                My approach doesn't takes the augment constexpr /
                template metaprogramming route, and maybe the route I'm
                taking is a dead-end.</div>
            </blockquote>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <font color="#3333ff"><font color="#000000">As I see
                    frames, they are orthogonal to templates and
                    constexpr. The examples I gave are template frames,
                    but we could have frames that are not templates. A
                    frame would be implicitly a constexpr as if the
                    parameters are know at compile time, the result is
                    obtained at compile time. If wewere&nbsp; able to build
                    grammar nodes at run-time, the frames could be
                    evaluated at run-time.<br>
                  </font></font></div>
            </blockquote>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <font color="#3333ff"><font color="#000000"> <br>
                    While at a first glance it could seem that frames
                    are nothing more than macros, their parameters are
                    language grammar nodes. This makes a big difference
                    and IMHO it opens to more elaborated transformation
                    techniques.</font><br>
                </font></div>
            </blockquote>
            <div><br>
              I would not say that it is a dead - end, but I think it
              needs more work when it comes to clarifying semantics and
              where operations should take place in relation i.e. to
              template definition, declaration and instantiation. </div>
          </div>
        </div>
      </div>
    </blockquote>
    Agreed.<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>But you are not at the same problem domain as the
              preprocessor right now, so you can't substitute it as you
              wish. Frames (as you are proposing them at least) are not
              exactly analogous to AST term rewriting macros (see
              Nimrod's <a moz-do-not-send="true"
                href="http://nimrod-code.org/">http://nimrod-code.org/</a>)
              either.</div>
          </div>
        </div>
      </div>
    </blockquote>
    This is quite close to what I'm looking for,even if the syntax is
    completely different and IIUC it is limited to expressions and
    statements. I would to be able to define any transformation inside
    the language.<br>
    Thanks for the pointer, if you have other like this one please send
    me them.<br>
    <br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> Because of the (for the time being!) ambiguous
              semantics you propose, they clash with established systems
              as templates and constexpr. Think again about why I asked
              as to when and where frame operations should take place.
              This is more important than it seems.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I understand your concern better now and unfortunately I have not
    taken enough time to be able do a deeper analysis to give you some
    answers :(<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
            </div>
            <div>&nbsp;<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF"><font
                  color="#3333ff"> </font>
                <div class="im"><br>
                  <blockquote type="cite">
                    <p dir="ltr">As for people who rely on external
                      tools for code generation, I think they are simply
                      trying to avoid current preprocessor
                      metaprogramming techniques for some subjective
                      disadvantage. Examples like boost's own use
                      demonstrates otherwise.<br>
                    </p>
                    <br>
                  </blockquote>
                </div>
                I have nothing against external tools, but I think this
                is off topic on this ML as far as the generation is
                external.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I did not understand your reply here. </div>
          </div>
        </div>
      </div>
    </blockquote>
    What I meant is that I didn't wanted to discuss anything related to
    external tools.<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>As I said, the preprocessor is fairly adequate if used
              properly; however it does require some inner knowledge of
              the techniques involved when doing metaprogramming with it
              and awareness of the necessary compromises in designing
              solutions with it. People not particularly eager to gain
              that knowledge, turn to external tools. Would I like to
              have something better? Of course I would, but if the
              preprocessor is all I am given within C++, then I must be
              ready to make the best use of it. And I have no problems
              with that either.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Neither me.<br>
    <blockquote
cite="mid:CAPkOUVgGKj=FcJdqBQOzZicMo70+g1Y5Qz-=oXJzi4G2xNbWOQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
            </div>
            <div>&nbsp;</div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF"> <br>
                I have used the preprocessor meta-programming techniques
                in TBoost.Enums and&nbsp; TBoost.Opaque and while this allows
                to experiment I would like to see something more
                appropriated introducing reflection in the language.<br>
                <br>
                Ville has suggested in [1] an approach that is more in
                line with the current language. operator member_name
                when member_name is a compile time string would define a
                new function. meta::invoke_member allows to call to a
                function identified by a compile time string.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I am aware of <span class=""><span
                  style="color:rgb(34,34,34)" class="">Ville
                  Voutilainen's approaches to problems like this and I
                  am quite a fan of his solutions when it comes to them.
                  But we are going to reflection now, which would derail
                  the entire thread into something different. Systematic
                  generation of valid C++ constructs for reducing hand -
                  written constructs is not something closely related to
                  reflection but as a "workaround" for the lack of said
                  feature at the language level. It is obviously that in
                  the end, you are actually trying to solve a compile /
                  run - time barrier problem, hence your interest in
                  reflection. Try thinking of the "frames" you are
                  proposing as something that should not however just
                  exist to help reflection purposes.<br>
                </span></span></div>
          </div>
        </div>
      </div>
    </blockquote>
    I'm&nbsp; just trying to explore the use cases as described in
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <span id="t-t" class="GFLL15SAYB">N3814 Call for Compile-Time
      Reflection Proposals and </span><br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    N3492 - Use Cases for Compile-Time Reflection (Rev. 2).<br>
    <br>
    I'll stop the frame concept thread here until I have something more
    concrete. Thanks for showing me that ideas can be good, but concrete
    proposal are much better.<br>
    <br>
    Apologies if I made you lost your time,<br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------040309030807080203020606--

.

On 11/13/13 7:59 AM, Vicente J. Botet Escriba wrote:
> The single way to control expansions I have identified so far and
> proposed in this post is the operator [[[]]]...

Somewhat off-topic, but if multiple brackets are to be used as
punctuators, it might be a good idea to make them such as part of the
token syntax. As with attributes, the intent isn't really to allow
whitespace between the constituent ['s.

--

---
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_538_25030586.1402763705366
Content-Type: text/plain; charset=UTF-8

Vicente,

Have you made any progress towards completing the design of the idea you
have presented in this thread?

--

---
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_538_25030586.1402763705366
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Vicente,<div><br></div><div>Have you made any progress towards completing the design of the idea you have presented in this thread?</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 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 />

------=_Part_538_25030586.1402763705366--

.

Le 14/06/14 18:35, Micha=C5=82 Dominiak a =C3=A9crit :
> Vicente,
>
> Have you made any progress towards completing the design of the idea=20
> you have presented in this thread?
>
Unfortunately no. I have not had (taken :() time for this.

Vicente

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

.