------=_Part_2686_475385525.1498619322727
Content-Type: multipart/alternative;
 boundary="----=_Part_2687_1403423091.1498619322727"

------=_Part_2687_1403423091.1498619322727
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(With apologies to those who will have already seen these musings in the=20
#future_standard channel of cpplang.slack)

There=E2=80=99s an interesting metaprogramming language/project called Terr=
a that I=20
think represents the fully general case of what metaclasses and the current=
=20
C++ compile-time programming proposals are working towards, but with Lua as=
=20
the meta-language and a new low-level, JIT-compiled language (called Terra)=
=20
as the =E2=80=9Cconcrete=E2=80=9D language.  It builds on the notion of mul=
ti-stage=20
programming (which I understand to mean that one compilation step can be=20
programmed in a way that controls a deeper compilation step, which can in=
=20
turn return first-class compilation metadata to the outer step).=20
 http://terralang.org/ (See particularly the Generative Programming section=
)

I=E2=80=99ve spent some time wondering if C++ compile-time programming coul=
d be=20
done in a similar way =E2=80=94 with `constexpr` being generalized more and=
 more,=20
we almost have what we would need to use C++ as its own metalanguage.

I think it would be a long, long shot to hope for the standard to mandate=
=20
the ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=9D layer of execution=
, so this=20
direction in C++ still wouldn=E2=80=99t have the full run-time generative p=
ower of=20
Terra =E2=80=94 All Terra programs are actually Lua programs that are run l=
ike=20
normal Lua programs, but it JITs the Terra portions then executes them as=
=20
it runs.  In C++ we have to have a compiler itself run (interpret) the=20
meta/constexpr portions.

But one thing I like about Terra is the very terse syntax for quoting Lua=
=20
in Terra code, and vice-versa.  Seeing `constexpr {...}` blocks in the=20
metaclasses paper reminded me of backtick-quoting in the Lua code of a=20
Terra program.  Terra code itself can also invoke meta-level Lua code by=20
quoting with `[=E2=80=A6]`, which reminds me of metaclasses=E2=80=99 `->`-i=
njections

Anyway, what=E2=80=99s being done with metaclasses reminded me of what I=E2=
=80=99d learned=20
previously about multi-stage compilation and Terra in particular; I thought=
=20
a pointer to another project in a similar vein might be interesting to=20
others as another reference point.

- - -

I do like how terse `-> {...}` code injections are in the metaclasses=20
proposal.  I wonder how strong interest would be in making `constexpr=20
{...}` terser.  Maybe something like `<- {...}`?  The symmetry of that=20
notation with code injections might be nice as a visual mnemonic, if=20
notions such as meta-metaclasses are supported=E2=80=A6
=20
I wonder if the generality of having a notion of a full stack of=20
meta-levels would be useful, or if there=E2=80=99s enough power in only one=
=20
meta-level.

I=E2=80=99m picturing that with a full stack, it could be handy to be able =
to=20
escape to a meta-meta level which can use code insertions to operate upon=
=20
the single-meta level.  An insertion inside that insertion would then take=
=20
it back down to the concrete level.  Generally, the default level is the=20
concrete level, and we use `<-{=E2=80=A6}` to go up one meta-level.

-Andy

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d8a01dc-367b-4979-8093-33cf60a0cb84%40isocpp.or=
g.

------=_Part_2687_1403423091.1498619322727
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>(With apologies to those who will have already seen t=
hese musings in the #future_standard channel of cpplang.slack)<br><br>There=
=E2=80=99s an interesting metaprogramming language/project called Terra tha=
t I think represents the fully general case of what metaclasses and the cur=
rent C++ compile-time programming proposals are working towards, but with L=
ua as the meta-language and a new low-level, JIT-compiled language (called =
Terra) as the =E2=80=9Cconcrete=E2=80=9D language. =C2=A0It builds on the n=
otion of multi-stage programming (which I understand to mean that one compi=
lation step can be programmed in a way that controls a deeper compilation s=
tep, which can in turn return first-class compilation metadata to the outer=
 step). =C2=A0http://terralang.org/ (See particularly the Generative Progra=
mming section)</div><div><br></div><div>I=E2=80=99ve spent some time wonder=
ing if C++ compile-time programming could be done in a similar way =E2=80=
=94 with `constexpr` being generalized more and more, we almost have what w=
e would need to use C++ as its own metalanguage.</div><div><br></div><div>I=
 think it would be a long, long shot to hope for the standard to mandate th=
e ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=9D layer of execution, =
so this direction in C++ still wouldn=E2=80=99t have the full run-time gene=
rative power of Terra =E2=80=94 All Terra programs are actually Lua program=
s that are run like normal Lua programs, but it JITs the Terra portions the=
n executes them as it runs. =C2=A0In C++ we have to have a compiler itself =
run (interpret) the meta/constexpr portions.<br></div><div><br></div><div>B=
ut one thing I like about Terra is the very terse syntax for quoting Lua in=
 Terra code, and vice-versa. =C2=A0Seeing `constexpr {...}` blocks in the m=
etaclasses paper reminded me of backtick-quoting in the Lua code of a Terra=
 program. =C2=A0Terra code itself can also invoke meta-level Lua code by qu=
oting with `[=E2=80=A6]`, which reminds me of metaclasses=E2=80=99 `-&gt;`-=
injections<br></div><div><br></div><div>Anyway, what=E2=80=99s being done w=
ith metaclasses reminded me of what I=E2=80=99d learned previously about mu=
lti-stage compilation and Terra in particular; I thought a pointer to anoth=
er project in a similar vein might be interesting to others as another refe=
rence point.<br></div><div><br></div><div>- - -<br></div><div><br></div><di=
v>I do like how terse `-&gt; {...}` code injections are in the metaclasses =
proposal. =C2=A0I wonder how strong interest would be in making `constexpr =
{...}` terser. =C2=A0Maybe something like `&lt;- {...}`? =C2=A0The symmetry=
 of that notation with code injections might be nice as a visual mnemonic, =
if notions such as meta-metaclasses are supported=E2=80=A6</div><div>=C2=A0=
<br></div><div>I wonder if the generality of having a notion of a full stac=
k of meta-levels would be useful, or if there=E2=80=99s enough power in onl=
y one meta-level.</div><div><br></div><div>I=E2=80=99m picturing that with =
a full stack, it could be handy to be able to escape to a meta-meta level w=
hich can use code insertions to operate upon the single-meta level. =C2=A0A=
n insertion inside that insertion would then take it back down to the concr=
ete level. =C2=A0Generally, the default level is the concrete level, and we=
 use `&lt;-{=E2=80=A6}` to go up one meta-level.<br><br>-Andy</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7d8a01dc-367b-4979-8093-33cf60a0cb84%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7d8a01dc-367b-4979-8093-33cf60a0cb84=
%40isocpp.org</a>.<br />

------=_Part_2687_1403423091.1498619322727--

------=_Part_2686_475385525.1498619322727--

.

------=_Part_1413_230308078.1499030800252
Content-Type: multipart/alternative;
 boundary="----=_Part_1414_220128872.1499030800252"

------=_Part_1414_220128872.1499030800252
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Could you please provide a link to the metaclasses paper you are referring=
=20
to?


Den onsdag 28 juni 2017 kl. 05:08:42 UTC+2 skrev Anthony Hall:
>
> (With apologies to those who will have already seen these musings in the=
=20
> #future_standard channel of cpplang.slack)
>
> There=E2=80=99s an interesting metaprogramming language/project called Te=
rra that=20
> I think represents the fully general case of what metaclasses and the=20
> current C++ compile-time programming proposals are working towards, but=
=20
> with Lua as the meta-language and a new low-level, JIT-compiled language=
=20
> (called Terra) as the =E2=80=9Cconcrete=E2=80=9D language.  It builds on =
the notion of=20
> multi-stage programming (which I understand to mean that one compilation=
=20
> step can be programmed in a way that controls a deeper compilation step,=
=20
> which can in turn return first-class compilation metadata to the outer=20
> step).  http://terralang.org/ (See particularly the Generative=20
> Programming section)
>
> I=E2=80=99ve spent some time wondering if C++ compile-time programming co=
uld be=20
> done in a similar way =E2=80=94 with `constexpr` being generalized more a=
nd more,=20
> we almost have what we would need to use C++ as its own metalanguage.
>
> I think it would be a long, long shot to hope for the standard to mandate=
=20
> the ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=9D layer of executi=
on, so this=20
> direction in C++ still wouldn=E2=80=99t have the full run-time generative=
 power of=20
> Terra =E2=80=94 All Terra programs are actually Lua programs that are run=
 like=20
> normal Lua programs, but it JITs the Terra portions then executes them as=
=20
> it runs.  In C++ we have to have a compiler itself run (interpret) the=20
> meta/constexpr portions.
>
> But one thing I like about Terra is the very terse syntax for quoting Lua=
=20
> in Terra code, and vice-versa.  Seeing `constexpr {...}` blocks in the=20
> metaclasses paper reminded me of backtick-quoting in the Lua code of a=20
> Terra program.  Terra code itself can also invoke meta-level Lua code by=
=20
> quoting with `[=E2=80=A6]`, which reminds me of metaclasses=E2=80=99 `->`=
-injections
>
> Anyway, what=E2=80=99s being done with metaclasses reminded me of what I=
=E2=80=99d learned=20
> previously about multi-stage compilation and Terra in particular; I thoug=
ht=20
> a pointer to another project in a similar vein might be interesting to=20
> others as another reference point.
>
> - - -
>
> I do like how terse `-> {...}` code injections are in the metaclasses=20
> proposal.  I wonder how strong interest would be in making `constexpr=20
> {...}` terser.  Maybe something like `<- {...}`?  The symmetry of that=20
> notation with code injections might be nice as a visual mnemonic, if=20
> notions such as meta-metaclasses are supported=E2=80=A6
> =20
> I wonder if the generality of having a notion of a full stack of=20
> meta-levels would be useful, or if there=E2=80=99s enough power in only o=
ne=20
> meta-level.
>
> I=E2=80=99m picturing that with a full stack, it could be handy to be abl=
e to=20
> escape to a meta-meta level which can use code insertions to operate upon=
=20
> the single-meta level.  An insertion inside that insertion would then tak=
e=20
> it back down to the concrete level.  Generally, the default level is the=
=20
> concrete level, and we use `<-{=E2=80=A6}` to go up one meta-level.
>
> -Andy
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c0f7f7fc-545b-458f-95a1-0e36ee1a82e7%40isocpp.or=
g.

------=_Part_1414_220128872.1499030800252
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Could you please provide a link to the metaclasses paper y=
ou are referring to?<div><br><br>Den onsdag 28 juni 2017 kl. 05:08:42 UTC+2=
 skrev Anthony Hall:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>(With apologies to those who will have already seen these mus=
ings in the #future_standard channel of cpplang.slack)<br><br>There=E2=80=
=99s an interesting metaprogramming language/project called Terra that I th=
ink represents the fully general case of what metaclasses and the current C=
++ compile-time programming proposals are working towards, but with Lua as =
the meta-language and a new low-level, JIT-compiled language (called Terra)=
 as the =E2=80=9Cconcrete=E2=80=9D language. =C2=A0It builds on the notion =
of multi-stage programming (which I understand to mean that one compilation=
 step can be programmed in a way that controls a deeper compilation step, w=
hich can in turn return first-class compilation metadata to the outer step)=
.. =C2=A0<a href=3D"http://terralang.org/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fterralang.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFCzPSkiVomkhU0v=
wjb3AqHDFVWIw&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fterralang.org%2F\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNFCzPSkiVomkhU0vwjb3AqHDFVWIw&#39;;return true;">http://terralan=
g.org/</a> (See particularly the Generative Programming section)</div><div>=
<br></div><div>I=E2=80=99ve spent some time wondering if C++ compile-time p=
rogramming could be done in a similar way =E2=80=94 with `constexpr` being =
generalized more and more, we almost have what we would need to use C++ as =
its own metalanguage.</div><div><br></div><div>I think it would be a long, =
long shot to hope for the standard to mandate the ability to JIT C++ as the=
 =E2=80=9Cconcrete=E2=80=9D layer of execution, so this direction in C++ st=
ill wouldn=E2=80=99t have the full run-time generative power of Terra =E2=
=80=94 All Terra programs are actually Lua programs that are run like norma=
l Lua programs, but it JITs the Terra portions then executes them as it run=
s. =C2=A0In C++ we have to have a compiler itself run (interpret) the meta/=
constexpr portions.<br></div><div><br></div><div>But one thing I like about=
 Terra is the very terse syntax for quoting Lua in Terra code, and vice-ver=
sa. =C2=A0Seeing `constexpr {...}` blocks in the metaclasses paper reminded=
 me of backtick-quoting in the Lua code of a Terra program. =C2=A0Terra cod=
e itself can also invoke meta-level Lua code by quoting with `[=E2=80=A6]`,=
 which reminds me of metaclasses=E2=80=99 `-&gt;`-injections<br></div><div>=
<br></div><div>Anyway, what=E2=80=99s being done with metaclasses reminded =
me of what I=E2=80=99d learned previously about multi-stage compilation and=
 Terra in particular; I thought a pointer to another project in a similar v=
ein might be interesting to others as another reference point.<br></div><di=
v><br></div><div>- - -<br></div><div><br></div><div>I do like how terse `-&=
gt; {...}` code injections are in the metaclasses proposal. =C2=A0I wonder =
how strong interest would be in making `constexpr {...}` terser. =C2=A0Mayb=
e something like `&lt;- {...}`? =C2=A0The symmetry of that notation with co=
de injections might be nice as a visual mnemonic, if notions such as meta-m=
etaclasses are supported=E2=80=A6</div><div>=C2=A0<br></div><div>I wonder i=
f the generality of having a notion of a full stack of meta-levels would be=
 useful, or if there=E2=80=99s enough power in only one meta-level.</div><d=
iv><br></div><div>I=E2=80=99m picturing that with a full stack, it could be=
 handy to be able to escape to a meta-meta level which can use code inserti=
ons to operate upon the single-meta level. =C2=A0An insertion inside that i=
nsertion would then take it back down to the concrete level. =C2=A0Generall=
y, the default level is the concrete level, and we use `&lt;-{=E2=80=A6}` t=
o go up one meta-level.<br><br>-Andy</div></div></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c0f7f7fc-545b-458f-95a1-0e36ee1a82e7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0f7f7fc-545b-458f-95a1-0e36ee1a82e7=
%40isocpp.org</a>.<br />

------=_Part_1414_220128872.1499030800252--

------=_Part_1413_230308078.1499030800252--

.

--f403045cd37c662f760553651716
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

P0707 by Herb Sutter:
https://www.google.co.uk/url?sa=3Dt&source=3Dweb&rct=3Dj&url=3Dhttp://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf&ved=3D0ahUKEwjOmvOf=
0ezUAhVfFMAKHfWWD6YQFghdMAU&usg=3DAFQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ

On Jul 2, 2017 10:26 PM, "Bengt Gustafsson" <bengt.gustafsson@beamways.com>
wrote:

> Could you please provide a link to the metaclasses paper you are referrin=
g
> to?
>
>
> Den onsdag 28 juni 2017 kl. 05:08:42 UTC+2 skrev Anthony Hall:
>>
>> (With apologies to those who will have already seen these musings in the
>> #future_standard channel of cpplang.slack)
>>
>> There=E2=80=99s an interesting metaprogramming language/project called T=
erra that
>> I think represents the fully general case of what metaclasses and the
>> current C++ compile-time programming proposals are working towards, but
>> with Lua as the meta-language and a new low-level, JIT-compiled language
>> (called Terra) as the =E2=80=9Cconcrete=E2=80=9D language.  It builds on=
 the notion of
>> multi-stage programming (which I understand to mean that one compilation
>> step can be programmed in a way that controls a deeper compilation step,
>> which can in turn return first-class compilation metadata to the outer
>> step).  http://terralang.org/ (See particularly the Generative
>> Programming section)
>>
>> I=E2=80=99ve spent some time wondering if C++ compile-time programming c=
ould be
>> done in a similar way =E2=80=94 with `constexpr` being generalized more =
and more,
>> we almost have what we would need to use C++ as its own metalanguage.
>>
>> I think it would be a long, long shot to hope for the standard to mandat=
e
>> the ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=9D layer of execut=
ion, so this
>> direction in C++ still wouldn=E2=80=99t have the full run-time generativ=
e power of
>> Terra =E2=80=94 All Terra programs are actually Lua programs that are ru=
n like
>> normal Lua programs, but it JITs the Terra portions then executes them a=
s
>> it runs.  In C++ we have to have a compiler itself run (interpret) the
>> meta/constexpr portions.
>>
>> But one thing I like about Terra is the very terse syntax for quoting Lu=
a
>> in Terra code, and vice-versa.  Seeing `constexpr {...}` blocks in the
>> metaclasses paper reminded me of backtick-quoting in the Lua code of a
>> Terra program.  Terra code itself can also invoke meta-level Lua code by
>> quoting with `[=E2=80=A6]`, which reminds me of metaclasses=E2=80=99 `->=
`-injections
>>
>> Anyway, what=E2=80=99s being done with metaclasses reminded me of what I=
=E2=80=99d
>> learned previously about multi-stage compilation and Terra in particular=
; I
>> thought a pointer to another project in a similar vein might be interest=
ing
>> to others as another reference point.
>>
>> - - -
>>
>> I do like how terse `-> {...}` code injections are in the metaclasses
>> proposal.  I wonder how strong interest would be in making `constexpr
>> {...}` terser.  Maybe something like `<- {...}`?  The symmetry of that
>> notation with code injections might be nice as a visual mnemonic, if
>> notions such as meta-metaclasses are supported=E2=80=A6
>>
>> I wonder if the generality of having a notion of a full stack of
>> meta-levels would be useful, or if there=E2=80=99s enough power in only =
one
>> meta-level.
>>
>> I=E2=80=99m picturing that with a full stack, it could be handy to be ab=
le to
>> escape to a meta-meta level which can use code insertions to operate upo=
n
>> the single-meta level.  An insertion inside that insertion would then ta=
ke
>> it back down to the concrete level.  Generally, the default level is the
>> concrete level, and we use `<-{=E2=80=A6}` to go up one meta-level.
>>
>> -Andy
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/c0f7f7fc-545b-458f-
> 95a1-0e36ee1a82e7%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c0f7f7fc-54=
5b-458f-95a1-0e36ee1a82e7%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAN4-sm1DHekGwBeXvE8vM8BrcNsZeEaZxnvk2UXc99-E0O6=
P_g%40mail.gmail.com.

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

<div dir=3D"auto">P0707 by Herb Sutter:=C2=A0<a href=3D"https://www.google.=
co.uk/url?sa=3Dt&amp;source=3Dweb&amp;rct=3Dj&amp;url=3Dhttp://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf&amp;ved=3D0ahUKEwjOmvOf0ez=
UAhVfFMAKHfWWD6YQFghdMAU&amp;usg=3DAFQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ">http=
s://www.google.co.uk/url?sa=3Dt&amp;source=3Dweb&amp;rct=3Dj&amp;url=3Dhttp=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf&amp;ved=3D0=
ahUKEwjOmvOf0ezUAhVfFMAKHfWWD6YQFghdMAU&amp;usg=3DAFQjCNGBH-aFb0DGA7dVN8APr=
HqfbuZVKQ</a></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Jul 2, 2017 10:26 PM, &quot;Bengt Gustafsson&quot; &lt;<a href=3D"mail=
to:bengt.gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>&gt; wro=
te:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Could you please provide a link to the metaclasses paper you are referring=
 to?<div><br><br>Den onsdag 28 juni 2017 kl. 05:08:42 UTC+2 skrev Anthony H=
all:<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"><div>(With apo=
logies to those who will have already seen these musings in the #future_sta=
ndard channel of cpplang.slack)<br><br>There=E2=80=99s an interesting metap=
rogramming language/project called Terra that I think represents the fully =
general case of what metaclasses and the current C++ compile-time programmi=
ng proposals are working towards, but with Lua as the meta-language and a n=
ew low-level, JIT-compiled language (called Terra) as the =E2=80=9Cconcrete=
=E2=80=9D language.=C2=A0 It builds on the notion of multi-stage programmin=
g (which I understand to mean that one compilation step can be programmed i=
n a way that controls a deeper compilation step, which can in turn return f=
irst-class compilation metadata to the outer step). =C2=A0<a href=3D"http:/=
/terralang.org/" rel=3D"nofollow" target=3D"_blank">http://terralang.org/</=
a> (See particularly the Generative Programming section)</div><div><br></di=
v><div>I=E2=80=99ve spent some time wondering if C++ compile-time programmi=
ng could be done in a similar way =E2=80=94 with `constexpr` being generali=
zed more and more, we almost have what we would need to use C++ as its own =
metalanguage.</div><div><br></div><div>I think it would be a long, long sho=
t to hope for the standard to mandate the ability to JIT C++ as the =E2=80=
=9Cconcrete=E2=80=9D layer of execution, so this direction in C++ still wou=
ldn=E2=80=99t have the full run-time generative power of Terra =E2=80=94 Al=
l Terra programs are actually Lua programs that are run like normal Lua pro=
grams, but it JITs the Terra portions then executes them as it runs.=C2=A0 =
In C++ we have to have a compiler itself run (interpret) the meta/constexpr=
 portions.<br></div><div><br></div><div>But one thing I like about Terra is=
 the very terse syntax for quoting Lua in Terra code, and vice-versa.=C2=A0=
 Seeing `constexpr {...}` blocks in the metaclasses paper reminded me of ba=
cktick-quoting in the Lua code of a Terra program.=C2=A0 Terra code itself =
can also invoke meta-level Lua code by quoting with `[=E2=80=A6]`, which re=
minds me of metaclasses=E2=80=99 `-&gt;`-injections<br></div><div><br></div=
><div>Anyway, what=E2=80=99s being done with metaclasses reminded me of wha=
t I=E2=80=99d learned previously about multi-stage compilation and Terra in=
 particular; I thought a pointer to another project in a similar vein might=
 be interesting to others as another reference point.<br></div><div><br></d=
iv><div>- - -<br></div><div><br></div><div>I do like how terse `-&gt; {...}=
` code injections are in the metaclasses proposal.=C2=A0 I wonder how stron=
g interest would be in making `constexpr {...}` terser.=C2=A0 Maybe somethi=
ng like `&lt;- {...}`?=C2=A0 The symmetry of that notation with code inject=
ions might be nice as a visual mnemonic, if notions such as meta-metaclasse=
s are supported=E2=80=A6</div><div>=C2=A0<br></div><div>I wonder if the gen=
erality of having a notion of a full stack of meta-levels would be useful, =
or if there=E2=80=99s enough power in only one meta-level.</div><div><br></=
div><div>I=E2=80=99m picturing that with a full stack, it could be handy to=
 be able to escape to a meta-meta level which can use code insertions to op=
erate upon the single-meta level.=C2=A0 An insertion inside that insertion =
would then take it back down to the concrete level.=C2=A0 Generally, the de=
fault level is the concrete level, and we use `&lt;-{=E2=80=A6}` to go up o=
ne meta-level.<br><br>-Andy</div></div></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c0f7f7fc-545b-458f-95a1-0e36ee1a82e7%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c0f7=
f7fc-545b-458f-<wbr>95a1-0e36ee1a82e7%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAN4-sm1DHekGwBeXvE8vM8BrcNsZeEaZxnvk=
2UXc99-E0O6P_g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN4-sm1DHekGwBeX=
vE8vM8BrcNsZeEaZxnvk2UXc99-E0O6P_g%40mail.gmail.com</a>.<br />

--f403045cd37c662f760553651716--

.

------=_Part_4774_1138904323.1499462512272
Content-Type: multipart/alternative;
 boundary="----=_Part_4775_784655723.1499462512272"

------=_Part_4775_784655723.1499462512272
Content-Type: text/plain; charset="UTF-8"

I find this proposal very interesting, as it offers a lot towards getting
rid of the preprocessor, and increases expressiveness of C++ significantly,
especially when using it to implement DSLs for different purposes.

In the Qt properties example each property which just needs the default
getter/setter functions still has a empty class head {} attached. I was
thinking that the forward declaration of a property could somehow be enough
to trigger some version of the constexpr code that generates the
getter/setter methods, so that the {} can be omitted.

I wonder whether the $class introducer could be replaced by inheriting from
class (or some other metaclass that in itself inherits from class):

class safe_union : class {
};

I would also like to see this extended to other parts of the C++ language,
at least statement, so that a safe switch, and other fancy control
structures can be defined. This would however require some kind of pattern
handling to describe what is supposed to follow the keyword itself. Not to
disrupt the parser too much this must of course be limited to a few select
constructs, basically the ones we already have, including: class-head,
statement-body, for-init-statement. This line of thinking leads to the
(probably quite old) idea of viewing this type of construct as constexpr
functions returning code. Assuming this stuff is in  a meta namespace we
would get something like:

constexpr meta::code safe_union(meta::class_head head) { ... }

constexpr meta::code safe_switch(meta::paren_expression,
meta::compound_statement) { ... }

Of course this would be much more comprehensive than the proposal and more
work to get done, but if this is an interesting direction it would be a bad
idea to choose a syntax now that basically prevents extension (in a
consistent way) in this direction. By this I mean to say that the meta
namespace does not have to have much contents in the first iteration, only
enough to implement the original proposal, but the constexpr function way
of description offers an easy extension path for future versions. Also it
does away with the need for a specai $ marker (for better or worse).

I would love my proposed for-expression (P0565) to be expressible using
this system. This could be used as a litmus test of something we would like
to be able to define.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/76ae7015-1d81-42de-99a5-a3f3ba107e09%40isocpp.org.

------=_Part_4775_784655723.1499462512272
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I find this proposal very interesting, as it offers a lot =
towards getting rid of the preprocessor, and increases expressiveness of C+=
+ significantly, especially when using it to implement DSLs for different p=
urposes.<div><br></div><div>In the Qt properties example each property whic=
h just needs the default getter/setter functions still has a empty class he=
ad {} attached. I was thinking that the forward declaration of a property c=
ould somehow be enough to trigger some version of the constexpr code that g=
enerates the getter/setter methods, so that the {} can be omitted.<br><div>=
<br></div><div>I wonder whether the $class introducer could be replaced by =
inheriting from class (or some other metaclass that in itself inherits from=
 class):</div><div><br></div><div>class safe_union : class {</div><div>};</=
div><div><br></div><div>I would also like to see this extended to other par=
ts of the C++ language, at least statement, so that a safe switch, and othe=
r fancy control structures can be defined. This would however require some =
kind of pattern handling to describe what is supposed to follow the keyword=
 itself. Not to disrupt the parser too much this must of course be limited =
to a few select constructs, basically the ones we already have, including: =
class-head, statement-body, for-init-statement. This line of thinking leads=
 to the (probably quite old) idea of viewing this type of construct as cons=
texpr functions returning code. Assuming this stuff is in =C2=A0a meta name=
space we would get something like:</div><div><br></div><div>constexpr meta:=
:code safe_union(meta::class_head head) { ... }</div><div><br></div><div>co=
nstexpr meta::code safe_switch(meta::paren_expression, meta::compound_state=
ment) { ... }</div><div><br></div><div>Of course this would be much more co=
mprehensive than the proposal and more work to get done, but if this is an =
interesting direction it would be a bad idea to choose a syntax now that ba=
sically prevents extension (in a consistent way) in this direction. By this=
 I mean to say that the meta namespace does not have to have much contents =
in the first iteration, only enough to implement the original proposal, but=
 the constexpr function way of description offers an easy extension path fo=
r future versions. Also it does away with the need for a specai $ marker (f=
or better or worse).</div><div><br></div><div>I would love my proposed for-=
expression (P0565) to be expressible using this system. This could be used =
as a litmus test of something we would like to be able to define.</div><div=
><br><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76ae7015-1d81-42de-99a5-a3f3ba107e09%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76ae7015-1d81-42de-99a5-a3f3ba107e09=
%40isocpp.org</a>.<br />

------=_Part_4775_784655723.1499462512272--

------=_Part_4774_1138904323.1499462512272--

.

On 2017-07-03 03:55, Jackie Kay wrote:
> P0707 by Herb Sutter:
> https://www.google.co.uk/url?sa=3Dt&source=3Dweb&rct=3Dj&url=3Dhttp://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf&ved=3D0ahUKEwjOmv=
Of0ezUAhVfFMAKHfWWD6YQFghdMAU&usg=3DAFQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ

Somewhat off topic (more general discussion of that paper, not really
related to anything in the OP), but I'm concerned by how little
knowledge of Qt's MOC is displayed in P0707. In particular, it gives
these examples of properties:

  Q_PROPERTY(int value READ get_value WRITE set_value)
  int  get_value() const { return value; }
  void set_value(int v)  { value =3D v; }

....but this is NOT AT ALL what real properties in Qt look like.

Here is a real example:

  Q_PROPERTY(bool readOnly READ isReadOnly WRITE setReadOnly)

Note that NEITHER the getter nor setter have names that are trivially
derived (e.g. string concatenation). This information needs to be
communicated somehow. It's also not obvious how the `property` results
in injection of methods into the parent class.

The *idea* of P0707 is interesting, but until someone can *demonstrate*
=E2=80=94 meaning, an actual functioning demo with real code, not some
ignorance-revealing hand-waving =E2=80=94 that it can replace MOC, I'm not
convinced that it is a viable, complete proposal. At the very least, I
feel like the MOC example should be removed, since it is really
something of a lie.

Another problem is locality of code. Due to compatibility constraints,
it is *critical* that the implementation of many functions is
non-inline. Maybe modules will alleviate or solve this, but until that
happens, the only way P0707 stands a chance of replacing MOC is to know,
somehow, if it should generate code because it is in the class's
implementation TU, or if it should generate only prototypes. Possibly I
missed it(? ...it's a long paper, after all), but I don't recall seeing
anything to this effect in the proposal.

I'd like to see, for example, how the proposed tools would implement this:

  qobject QLineEdit : public QWidget
  {
    qproperty<bool> modified{
      .read =3D isModified,
      .write =3D setModified
    };
    qproperty<QString> text{
      .read =3D text,
      .write =3D setText,
      .notify =3D textChanged
    };
    // ...

  public:
    bool isModified() const; // note: NOT inline!
    void setModified(bool); // note: NOT inline!
    // ...
    void setText(QString);
    void setText(/*... some overload ...*/);

  public: // signals
    qsignal textModified();
  };

Besides the issue of where certain special function definitions reside,
as discussed above, some issues that this would need to address that
P0707 does not obviously cover include:

- Implicit inheritance when the class is already a descendant of
QObject. (Practically speaking, the above example is inaccurate; there
would almost certainly be a $qwidget meta-class in addition to $qobject,
but I've written it that way to demonstrate this issue.) Presumably
reflection will be able to sort this out, but it seems important enough
to not just gloss over.

- Terse syntax for linking a meta-object (note: the $qproperty must
result in code generation, but otherwise must eventually disappear from
the class without creating members) to other members of the enclosing
class. I've used named initializers as the most terse but still
syntactically valid construct that came to mind. Moving the definitions
of the get/set functions into the $qproperty is not appropriate; in most
cases, they cannot be inline due to PIMPL, and writing thunks is
pointless repetition. The approach shown is MUCH more palatable than
what is presented in P0707. (Ideally, this should also be able to accept
not only an identifier which is a member function of the parent class,
but one with a specific signature, without choking and dying in the face
of overloads. However, use of a string literal might be palatable;
presumably code generation can turn it back into an identifier.)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/78b53416-7895-a96f-2459-2fc2541594fb%40gmail.com=
..

.

------=_Part_1614_181290166.1500065177525
Content-Type: multipart/alternative;
 boundary="----=_Part_1615_662998991.1500065177525"

------=_Part_1615_662998991.1500065177525
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think, it's time to C++ have anotations.

Em quarta-feira, 28 de junho de 2017 00:08:42 UTC-3, Anthony Hall escreveu:
>
> (With apologies to those who will have already seen these musings in the=
=20
> #future_standard channel of cpplang.slack)
>
> There=E2=80=99s an interesting metaprogramming language/project called Te=
rra that=20
> I think represents the fully general case of what metaclasses and the=20
> current C++ compile-time programming proposals are working towards, but=
=20
> with Lua as the meta-language and a new low-level, JIT-compiled language=
=20
> (called Terra) as the =E2=80=9Cconcrete=E2=80=9D language.  It builds on =
the notion of=20
> multi-stage programming (which I understand to mean that one compilation=
=20
> step can be programmed in a way that controls a deeper compilation step,=
=20
> which can in turn return first-class compilation metadata to the outer=20
> step).  http://terralang.org/ (See particularly the Generative=20
> Programming section)
>
> I=E2=80=99ve spent some time wondering if C++ compile-time programming co=
uld be=20
> done in a similar way =E2=80=94 with `constexpr` being generalized more a=
nd more,=20
> we almost have what we would need to use C++ as its own metalanguage.
>
> I think it would be a long, long shot to hope for the standard to mandate=
=20
> the ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=9D layer of executi=
on, so this=20
> direction in C++ still wouldn=E2=80=99t have the full run-time generative=
 power of=20
> Terra =E2=80=94 All Terra programs are actually Lua programs that are run=
 like=20
> normal Lua programs, but it JITs the Terra portions then executes them as=
=20
> it runs.  In C++ we have to have a compiler itself run (interpret) the=20
> meta/constexpr portions.
>
> But one thing I like about Terra is the very terse syntax for quoting Lua=
=20
> in Terra code, and vice-versa.  Seeing `constexpr {...}` blocks in the=20
> metaclasses paper reminded me of backtick-quoting in the Lua code of a=20
> Terra program.  Terra code itself can also invoke meta-level Lua code by=
=20
> quoting with `[=E2=80=A6]`, which reminds me of metaclasses=E2=80=99 `->`=
-injections
>
> Anyway, what=E2=80=99s being done with metaclasses reminded me of what I=
=E2=80=99d learned=20
> previously about multi-stage compilation and Terra in particular; I thoug=
ht=20
> a pointer to another project in a similar vein might be interesting to=20
> others as another reference point.
>
> - - -
>
> I do like how terse `-> {...}` code injections are in the metaclasses=20
> proposal.  I wonder how strong interest would be in making `constexpr=20
> {...}` terser.  Maybe something like `<- {...}`?  The symmetry of that=20
> notation with code injections might be nice as a visual mnemonic, if=20
> notions such as meta-metaclasses are supported=E2=80=A6
> =20
> I wonder if the generality of having a notion of a full stack of=20
> meta-levels would be useful, or if there=E2=80=99s enough power in only o=
ne=20
> meta-level.
>
> I=E2=80=99m picturing that with a full stack, it could be handy to be abl=
e to=20
> escape to a meta-meta level which can use code insertions to operate upon=
=20
> the single-meta level.  An insertion inside that insertion would then tak=
e=20
> it back down to the concrete level.  Generally, the default level is the=
=20
> concrete level, and we use `<-{=E2=80=A6}` to go up one meta-level.
>
> -Andy
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f80b0a8a-be0a-4076-b9c2-daf257d587ca%40isocpp.or=
g.

------=_Part_1615_662998991.1500065177525
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think, it&#39;s time to C++ have anotations.<br><br>Em q=
uarta-feira, 28 de junho de 2017 00:08:42 UTC-3, Anthony Hall  escreveu:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>(With apolo=
gies to those who will have already seen these musings in the #future_stand=
ard channel of cpplang.slack)<br><br>There=E2=80=99s an interesting metapro=
gramming language/project called Terra that I think represents the fully ge=
neral case of what metaclasses and the current C++ compile-time programming=
 proposals are working towards, but with Lua as the meta-language and a new=
 low-level, JIT-compiled language (called Terra) as the =E2=80=9Cconcrete=
=E2=80=9D language. =C2=A0It builds on the notion of multi-stage programmin=
g (which I understand to mean that one compilation step can be programmed i=
n a way that controls a deeper compilation step, which can in turn return f=
irst-class compilation metadata to the outer step). =C2=A0<a href=3D"http:/=
/terralang.org/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fterralang.org%2F\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFCzPSkiVomkhU0vwjb3AqHDFVWIw&#39;;return=
 true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fterralang.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFCzPSkiVomkhU=
0vwjb3AqHDFVWIw&#39;;return true;">http://terralang.org/</a> (See particula=
rly the Generative Programming section)</div><div><br></div><div>I=E2=80=99=
ve spent some time wondering if C++ compile-time programming could be done =
in a similar way =E2=80=94 with `constexpr` being generalized more and more=
, we almost have what we would need to use C++ as its own metalanguage.</di=
v><div><br></div><div>I think it would be a long, long shot to hope for the=
 standard to mandate the ability to JIT C++ as the =E2=80=9Cconcrete=E2=80=
=9D layer of execution, so this direction in C++ still wouldn=E2=80=99t hav=
e the full run-time generative power of Terra =E2=80=94 All Terra programs =
are actually Lua programs that are run like normal Lua programs, but it JIT=
s the Terra portions then executes them as it runs. =C2=A0In C++ we have to=
 have a compiler itself run (interpret) the meta/constexpr portions.<br></d=
iv><div><br></div><div>But one thing I like about Terra is the very terse s=
yntax for quoting Lua in Terra code, and vice-versa. =C2=A0Seeing `constexp=
r {...}` blocks in the metaclasses paper reminded me of backtick-quoting in=
 the Lua code of a Terra program. =C2=A0Terra code itself can also invoke m=
eta-level Lua code by quoting with `[=E2=80=A6]`, which reminds me of metac=
lasses=E2=80=99 `-&gt;`-injections<br></div><div><br></div><div>Anyway, wha=
t=E2=80=99s being done with metaclasses reminded me of what I=E2=80=99d lea=
rned previously about multi-stage compilation and Terra in particular; I th=
ought a pointer to another project in a similar vein might be interesting t=
o others as another reference point.<br></div><div><br></div><div>- - -<br>=
</div><div><br></div><div>I do like how terse `-&gt; {...}` code injections=
 are in the metaclasses proposal. =C2=A0I wonder how strong interest would =
be in making `constexpr {...}` terser. =C2=A0Maybe something like `&lt;- {.=
...}`? =C2=A0The symmetry of that notation with code injections might be nic=
e as a visual mnemonic, if notions such as meta-metaclasses are supported=
=E2=80=A6</div><div>=C2=A0<br></div><div>I wonder if the generality of havi=
ng a notion of a full stack of meta-levels would be useful, or if there=E2=
=80=99s enough power in only one meta-level.</div><div><br></div><div>I=E2=
=80=99m picturing that with a full stack, it could be handy to be able to e=
scape to a meta-meta level which can use code insertions to operate upon th=
e single-meta level. =C2=A0An insertion inside that insertion would then ta=
ke it back down to the concrete level. =C2=A0Generally, the default level i=
s the concrete level, and we use `&lt;-{=E2=80=A6}` to go up one meta-level=
..<br><br>-Andy</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f80b0a8a-be0a-4076-b9c2-daf257d587ca%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f80b0a8a-be0a-4076-b9c2-daf257d587ca=
%40isocpp.org</a>.<br />

------=_Part_1615_662998991.1500065177525--

------=_Part_1614_181290166.1500065177525--

.

------=_Part_1640_343537102.1500082288668
Content-Type: multipart/alternative;
 boundary="----=_Part_1641_2089445449.1500082288668"

------=_Part_1641_2089445449.1500082288668
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, July 14, 2017 at 3:36:08 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-07-03 03:55, Jackie Kay wrote:=20
> > P0707 by Herb Sutter:=20
> >=20
> https://www.google.co.uk/url?sa=3Dt&source=3Dweb&rct=3Dj&url=3Dhttp://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf&ved=3D0ahUKEwjOmv=
Of0ezUAhVfFMAKHfWWD6YQFghdMAU&usg=3DAFQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ=20
>
> Somewhat off topic (more general discussion of that paper, not really=20
> related to anything in the OP), but I'm concerned by how little=20
> knowledge of Qt's MOC is displayed in P0707. In particular, it gives=20
> these examples of properties:=20
>
>   Q_PROPERTY(int value READ get_value WRITE set_value)=20
>   int  get_value() const { return value; }=20
>   void set_value(int v)  { value =3D v; }=20
>
> ...but this is NOT AT ALL what real properties in Qt look like.=20
>
> Here is a real example:=20
>
>   Q_PROPERTY(bool readOnly READ isReadOnly WRITE setReadOnly)=20
>
> Note that NEITHER the getter nor setter have names that are trivially=20
> derived (e.g. string concatenation). This information needs to be=20
> communicated somehow. It's also not obvious how the `property` results=20
> in injection of methods into the parent class.=20
>
> The *idea* of P0707 is interesting, but until someone can *demonstrate*=
=20
> =E2=80=94 meaning, an actual functioning demo with real code, not some=20
> ignorance-revealing hand-waving =E2=80=94 that it can replace MOC, I'm no=
t=20
> convinced that it is a viable, complete proposal. At the very least, I=20
> feel like the MOC example should be removed, since it is really=20
> something of a lie.
>

It's not a "viable, complete proposal", and I don't think the authors see=
=20
it that way. Even the MOC section is specifically called out as being a=20
"(sketch)". The goal of P0707 is to be moving in a direction where you can=
=20
eventually replace MOC. But I don't think anyone involved with that paper=
=20
believes that the proposed changes alone are sufficient to get the job done=
..

Another problem is locality of code. Due to compatibility constraints,=20
> it is *critical* that the implementation of many functions is=20
> non-inline. Maybe modules will alleviate or solve this,


Well, modules is gonna happen, and they're gonna happen a *lot* sooner than=
=20
any form of reflection (standard committee craziness notwithstanding).=20
Modules is almost a TS at this point, with two independent implementations.=
=20
Static introspective reflection is still in the gestation stage.

So continuing to design features for a pre-modules world is not a good=20
place to start.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/44d92f47-f9f6-47e6-a1ee-500d6fd835b9%40isocpp.or=
g.

------=_Part_1641_2089445449.1500082288668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, July 14, 2017 at 3:36:08 PM UTC-4, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-07-03 03:55,=
 Jackie Kay wrote:
<br>&gt; P0707 by Herb Sutter:
<br>&gt; <a href=3D"https://www.google.co.uk/url?sa=3Dt&amp;source=3Dweb&am=
p;rct=3Dj&amp;url=3Dhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017=
/p0707r0.pdf&amp;ved=3D0ahUKEwjOmvOf0ezUAhVfFMAKHfWWD6YQFghdMAU&amp;usg=3DA=
FQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;https://www.google.co.uk/url?sa\x3dt\x26source\x=
3dweb\x26rct\x3dj\x26url\x3dhttp://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2017/p0707r0.pdf\x26ved\x3d0ahUKEwjOmvOf0ezUAhVfFMAKHfWWD6YQFghdMAU\x26=
usg\x3dAFQjCNGBH-aFb0DGA7dVN8APrHqfbuZVKQ&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;https://www.google.co.uk/url?sa\x3dt\x26source\x3dweb\x26rct\=
x3dj\x26url\x3dhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p070=
7r0.pdf\x26ved\x3d0ahUKEwjOmvOf0ezUAhVfFMAKHfWWD6YQFghdMAU\x26usg\x3dAFQjCN=
GBH-aFb0DGA7dVN8APrHqfbuZVKQ&#39;;return true;">https://www.google.co.uk/ur=
l?<wbr>sa=3Dt&amp;source=3Dweb&amp;rct=3Dj&amp;url=3D<wbr>http://www.open-s=
td.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p0707r0.pdf&amp;ved=3D<wbr=
>0ahUKEwjOmvOf0ezUAhVfFMAKHfWWD<wbr>6YQFghdMAU&amp;usg=3DAFQjCNGBH-<wbr>aFb=
0DGA7dVN8APrHqfbuZVKQ</a>
<br>
<br>Somewhat off topic (more general discussion of that paper, not really
<br>related to anything in the OP), but I&#39;m concerned by how little
<br>knowledge of Qt&#39;s MOC is displayed in P0707. In particular, it give=
s
<br>these examples of properties:
<br>
<br>=C2=A0 Q_PROPERTY(int value READ get_value WRITE set_value)
<br>=C2=A0 int =C2=A0get_value() const { return value; }
<br>=C2=A0 void set_value(int v) =C2=A0{ value =3D v; }
<br>
<br>...but this is NOT AT ALL what real properties in Qt look like.
<br>
<br>Here is a real example:
<br>
<br>=C2=A0 Q_PROPERTY(bool readOnly READ isReadOnly WRITE setReadOnly)
<br>
<br>Note that NEITHER the getter nor setter have names that are trivially
<br>derived (e.g. string concatenation). This information needs to be
<br>communicated somehow. It&#39;s also not obvious how the `property` resu=
lts
<br>in injection of methods into the parent class.
<br>
<br>The *idea* of P0707 is interesting, but until someone can *demonstrate*
<br>=E2=80=94 meaning, an actual functioning demo with real code, not some
<br>ignorance-revealing hand-waving =E2=80=94 that it can replace MOC, I&#3=
9;m not
<br>convinced that it is a viable, complete proposal. At the very least, I
<br>feel like the MOC example should be removed, since it is really
<br>something of a lie.<br></blockquote><div><br>It&#39;s not a &quot;viabl=
e, complete proposal&quot;, and I don&#39;t think the authors see it that w=
ay. Even the MOC section is specifically called out as being a &quot;(sketc=
h)&quot;. The goal of P0707 is to be moving in a direction where you can ev=
entually replace MOC. But I don&#39;t think anyone involved with that paper=
 believes that the proposed changes alone are sufficient to get the job don=
e.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Another problem is locality of code. Due to compatibility constraints,
<br>it is *critical* that the implementation of many functions is
<br>non-inline. Maybe modules will alleviate or solve this,</blockquote><di=
v><br>Well, modules is gonna happen, and they&#39;re gonna happen a <i>lot<=
/i> sooner than any form of reflection (standard committee craziness notwit=
hstanding). Modules is almost a TS at this point, with two independent impl=
ementations. Static introspective reflection is still in the gestation stag=
e.<br><br>So continuing to design features for a pre-modules world is not a=
 good place to start.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/44d92f47-f9f6-47e6-a1ee-500d6fd835b9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44d92f47-f9f6-47e6-a1ee-500d6fd835b9=
%40isocpp.org</a>.<br />

------=_Part_1641_2089445449.1500082288668--

------=_Part_1640_343537102.1500082288668--

.