------=_Part_844_1360299663.1540552555132
Content-Type: multipart/alternative;
 boundary="----=_Part_845_527868204.1540552555132"

------=_Part_845_527868204.1540552555132
Content-Type: text/plain; charset="UTF-8"

(Request for comments. Disclaimers: There may be possibly premature and
informal points and misnomers. It is yet not ready for being presented in a
paper.)

"I didn't see a single facility for totally replacing macros while still
remaining sufficiently flexible and efficient."

The term "macro" has a huge set of extensions. Macros are used to *extend *a
language with user-defined identifiers, and the language feature named
"macro" used in the C++ is only an awkward case. I'd like to see macros in
C++ being replaced by some saner choices, whether they are still named
"macros". For example, hygienic macros can even totally replace most of
built-in keywords with accurate formal definitions; modern variants of
FEXPRs <https://en.wikipedia.org/wiki/Fexpr> (e.g. in vau calculi
<https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf>,
or the modified quote operator
<http://folk.uio.no/jkleiser/pico/doc/faq.html#lambda>) can be intuitively
strictly more powerful than hygienic macros about abilities of abstraction
<http://fexpr.blogspot.com/2013/12/abstractive-power.html>. Note in the
aspect of designing and drafting rules in a language specialization,
hygienic macros are far more closed to FEXPRs (even not named "macros"),
rather than C++ ones. The differences root far more than paradigms, but
(for instance) in view of fundamental methodologies (formalism v.
intuitionalism, so on) and language design disciplines (translating v.
rewriting, multi-staged v. single-staged, "static" v. "dynamic", type-based
v. unityped, manifest v. inferred, nominal v. structural...) and I don't
see all of them have been categorized into the so-called paradigms. *Missing
insights of them maybe more dangerous to the disordered evolution of
features.*

"Gradual transition and co-existence of older features with new also allows
us to benefit from feedback in the evolutionary process. That's good
engineering as opposed to hopeful philosophizing. "

I'd still agree on preserving features like macros as the status quo, with
more realistic reasons: it is just too difficult to get it done. The
changes in the evolution will lead to too much work in the core language
design, and making a "clean break" on features involving disciplines seems
even impossible.

As a user of the language, I have more minor reasons. To make an industrial
language harder to teach is stupid; I don't want to see another "export" in
the language, before a feasible way of "gradual transition" is found. But
anyway, if that cannot be done, features will still bloat - with or without
thinking of paradigm shift.

On the other hand, co-existence of some features is already considerably
bloated. This does not seem like a case of "good engineering" at all. If we
need a better one, the first problem to be resolved is *how to systemically
prevent the origins of the bloat*. Avoiding blind belief on paradigm shifts
seems hardly enough.



--
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/3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54%40isocpp.org.

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

<div dir=3D"ltr">(Request for comments. Disclaimers: There may be possibly =
premature and informal points and misnomers. It is yet not ready for being =
presented in a paper.)<br><br>&quot;I didn&#39;t see a single facility for =
totally replacing macros while still remaining sufficiently flexible and ef=
ficient.&quot;<br><br>The term &quot;macro&quot; has a huge set of extensio=
ns. Macros are used to <i>extend </i>a language with user-defined identifie=
rs, and the language feature named &quot;macro&quot; used in the C++ is onl=
y an awkward case. I&#39;d like to see macros in C++ being replaced by some=
 saner choices, whether they are still named &quot;macros&quot;. For exampl=
e, hygienic macros can even totally replace most of built-in keywords with =
accurate formal definitions; modern variants of <a href=3D"https://en.wikip=
edia.org/wiki/Fexpr">FEXPRs</a> (e.g. in <a href=3D"https://web.wpi.edu/Pub=
s/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf">vau calculi</a>,=
 or the modified <a href=3D"http://folk.uio.no/jkleiser/pico/doc/faq.html#l=
ambda">quote operator</a>) can be intuitively strictly more powerful than h=
ygienic macros about <a href=3D"http://fexpr.blogspot.com/2013/12/abstracti=
ve-power.html">abilities of abstraction</a>. Note in the aspect of designin=
g and drafting rules in a language specialization, hygienic macros are far =
more closed to FEXPRs (even not named &quot;macros&quot;), rather than C++ =
ones. The differences root far more than paradigms, but (for instance) in v=
iew of fundamental methodologies (formalism v. intuitionalism, so on) and l=
anguage design disciplines (translating v. rewriting, multi-staged v. singl=
e-staged, &quot;static&quot; v. &quot;dynamic&quot;, type-based v. unityped=
, manifest v. inferred, nominal v. structural...) and I don&#39;t see all o=
f them have been categorized into the so-called paradigms. <i>Missing insig=
hts of them maybe more dangerous to the disordered evolution of features.</=
i> <br><br>&quot;Gradual transition and co-existence of older features with=
 new also allows us to benefit from feedback in the evolutionary process. T=
hat&#39;s good engineering as opposed to hopeful philosophizing. &quot;<br>=
<br>I&#39;d still agree on preserving features like macros as the status qu=
o, with more realistic reasons: it is just too difficult to get it done. Th=
e changes in the evolution will lead to too much work in the core language =
design, and making a &quot;clean break&quot; on features involving discipli=
nes seems even impossible.<br><br>As a user of the language, I have more mi=
nor reasons. To make an industrial language harder to teach is stupid; I do=
n&#39;t want to see another &quot;export&quot; in the language, before a fe=
asible way of &quot;gradual transition&quot; is found. But anyway, if that =
cannot be done, features will still bloat - with or without thinking of par=
adigm shift.<br><br>On the other hand, co-existence of some features is alr=
eady considerably bloated. This does not seem like a case of &quot;good eng=
ineering&quot; at all. If we need a better one, the first problem to be res=
olved is <i>how to systemically prevent the origins of the bloat</i>. Avoid=
ing blind belief on paradigm shifts seems hardly enough.<br><br><br><br></d=
iv>

<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/3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54=
%40isocpp.org</a>.<br />

------=_Part_845_527868204.1540552555132--

------=_Part_844_1360299663.1540552555132--

.