FrankHB1989
2018-10-26 11:15:55 UTC
(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.
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+***@isocpp.org.
To post to this group, send email to std-***@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.
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+***@isocpp.org.
To post to this group, send email to std-***@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.