Topic: Extending constexpr to AST macros


Author: snk_kid <korcan.hussein@googlemail.com>
Date: Sat, 26 Jul 2014 03:20:13 -0700 (PDT)
Raw View
------=_Part_1685_754750845.1406370013870
Content-Type: text/plain; charset=UTF-8

Hi, it seems to me that generalized constant expressions could eventually
be extended to an AST based macro system & user-defined attributes in C++
thus making various (potential) proposals redundant like the suggestion of
adding mixins or making templates more and more complex.

I believe we should keep templates for what they were originally designed
for (bounded with concepts) parametric polymorphism and not making them
more and more complex for the sake of supporting meta-programming which
isn't really a good solution to the problem to start with.

Of-course we can still keep it as the way it is now for type-level
computations, a lightweight form of meta-programming and consexpr for real
meta-programming. GHC Haskell is like this, it has extensions to standard
Haskell's type system adding type-families and associated types for
type-level computations and (data-type) generic programming but also has an
AST Macro system (Template Haskell) with syntax extensions for everything
else.

With constexpr as an AST macro system we would have:

   - A meta-language that is a slightly larger super-set of the
   object-language, not a different language like with template
   meta-programming
   - Respects and well integrate with a Module system, as opposed to
   textual macros like C/C++ Macros
   - Readable, accessible and maintainable by all people who knows C++ and
   not just the 1%.
   - Could more easily support debugging tools for meta-programming which
   is non-existent with template meta-programming when making mistakes.
   - Could be extended further to support user-defined attributes in C++
   like in Nemerle & .NET attributes.
   - Could be extended further to support syntax extensions in C++ like in
   some other AST macro systems.
   - With support for syntax extensions could make C++ a simpler language
   making lots of little highly specific proposals redundant.

I think a good place to look at is the programming language Nermele, it has
a type-safe hygienic AST macro system with support for syntax extensions
that was designed to work well with OO. It gives the programmer a way to
also add user-defined attributes in .NET to do various types of code
transformations on classes:

https://github.com/rsdn/nemerle/wiki/Macros-tutorial

I'm not suggesting the same syntactic as Nermele should be used, but just
to highlight what a good macro system looks especially in the presence of
OO features.

I know this is non-trivial and I think the biggest hurdle would be to
standardize an AST library to be expose compiler internals and be
transformed by constexpr functions but then again there are already
proposals in the works to standardize a compile-time reflection library
with templates that covers many cases that an AST library would require.

--

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

<div dir=3D"ltr">Hi, it seems to me that generalized constant expressions c=
ould eventually be extended to an AST based macro system &amp; user-defined=
 attributes in C++ thus making various (potential) proposals redundant like=
 the suggestion of adding mixins or making templates more and more complex.=
<br><br>I believe we should keep templates for what they were originally de=
signed for (bounded with concepts) parametric polymorphism and not making t=
hem more and more complex for the sake of supporting meta-programming which=
 isn't really a good solution to the problem to start with.<br><br>Of-cours=
e we can still keep it as the way it is now for type-level computations, a =
lightweight form of meta-programming and consexpr for real meta-programming=
.. GHC Haskell is like this, it has extensions to standard Haskell's type sy=
stem adding type-families and associated types for type-level computations =
and (data-type) generic programming but also has an AST Macro system (Templ=
ate Haskell) with syntax extensions for everything else.<br><br>With conste=
xpr as an AST macro system we would have:<br><ul><li>A meta-language that i=
s a slightly larger super-set of the object-language, not a different langu=
age like with template meta-programming</li><li>Respects and well integrate=
 with a Module system, as opposed to textual macros like C/C++ Macros<br></=
li><li>Readable, accessible and maintainable by all people who knows C++ an=
d not just the 1%.<br></li><li>Could more easily support debugging tools fo=
r meta-programming which is non-existent with template meta-programming whe=
n making mistakes.</li><li>Could be extended further to support user-define=
d attributes in C++ like in Nemerle &amp; .NET attributes.<br></li><li>Coul=
d be extended further to support syntax extensions in C++ like in some othe=
r AST macro systems.</li><li>With support for syntax extensions could make =
C++ a simpler language making lots of little highly specific proposals redu=
ndant.<br></li></ul><p>I think a good place to look at is the programming l=
anguage Nermele, it has a type-safe hygienic AST macro system with support =
for syntax extensions that was designed to work well with OO. It gives the =
programmer a way to also add user-defined attributes in .NET to do various =
types of code transformations on classes:</p><p>https://github.com/rsdn/nem=
erle/wiki/Macros-tutorial</p><p>I'm not suggesting the same syntactic as Ne=
rmele should be used, but just to highlight what a good macro system looks =
especially in the presence of OO features.<br></p><p>I know this is non-tri=
vial and I think the biggest hurdle would be to standardize an AST library =
to be expose compiler internals and be transformed by constexpr functions b=
ut then again there are already proposals in the works to standardize a com=
pile-time reflection library with templates that covers many cases that an =
AST library would require.</p><p></p><p></p></div>

<p></p>

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

------=_Part_1685_754750845.1406370013870--

.