5 ms·

It would be cool to have the entire language and runtime available at compile-time like in Lisp

kazinator 1y ago
It would be cool, except for the entire language that is available at compile-time being C++, and thus entirely unsuitable for manipulating C++ programs.
- gpderetta 1y ago
  Yes. It is not like C++ compilers are written in C++.
klipt 1y ago
Circle C++ does that
- dataflow 1y ago
  Could you show some examples?
chrisrodrigue 1y ago
...isn't that what templates were made for? Template metaprogramming in C++ is Turing-complete.
- pjmlp 1y ago
  Not at all, originally template metaprogramming was discovered by accident. Cannot recall any longer if the original article on the matter appeared on The C/C++ Users Journal or Dr. Dobbs. Eventually it started to get abused and the Turing completeness has been discovered. Since C++11, the approach to a more sane way to do metaprogramming with templates has been improving. Instead of tag dispatch, ADL and SFINAE, we can make use of concepts, if constexpr/eval/init, type traits, and eventually reflection, instead of the old clunky ways.
  - troutwine 1y ago
    “C++ Templates are Turing Complete” by Todd L. Veldhuizen has the history of discovery, early elaboration.
    - omoikane 1y ago
      Link to paper: http://web.archive.org/web/20131101122512/http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.pdf http://web.archive.org/web/20131101122512/http://ubietylab.n... Via "Accidentally Turing-Complete": https://news.ycombinator.com/item?id=30189780 https://news.ycombinator.com/item?id=30189780
- einpoklum 1y ago
  Templates are semi-accidentally Turing-complete. They were intended for writing compile-time-generic, run-time-concrete functions and types - but it turned out you could use them, along with the overload resolution mechanisms, to compute things. The Turing-completeness involves recursive use. Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less. Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)
jjmarr 1y ago
This already exists with macros, templates, and compiler extensions, if you want completely unusable/unreadable code that takes forever to build.
- pjmlp 1y ago
  Depends on the C++ version. With C++23 can be made relatively readable, and with the right compiler, builds within sensible timeframe.
  - jjmarr 1y ago
    C++23 doesn't have full reflection yet. That's coming in C++26. I've seen the vast majority of build time in a very large C++23 project be taken up by reflection in fmtlib and magic_enum because both have to use templates (I think).
    - pjmlp 1y ago
      I didn't said it has, rather that template metaprogramming can be both readable, and with the right compiler relatively fast.
    - vitaut 1y ago
      {fmt} doesn't use reflection and is optimized for build speed using type erasure: https://vitaut.net/posts/2024/faster-cpp-compile-times/ https://vitaut.net/posts/2024/faster-cpp-compile-times/
MrRadar 1y ago
The D language basically does that. You can write D programs that evaluate D code at compile time to generate strings of new D code which you can then basically compile-time eval into your code as needed. Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages and it's easier to read than Rust macros or C++ template metaprogramming.
- TOGoS 1y ago
  Every time I hear about D it sounds awesome. I actually used it to prototype an image collage-composing algorithm which I then rewrote in Scala[1], and the D version might have been nicer to write. The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk. [1] One of the algorithms used by https://github.com/TOGoS/PicGrid https://github.com/TOGoS/PicGrid
- AdieuToLogic 1y ago
  > Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages ... Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2]. Not comparing Scala to D, just identifying a language with similar functionality. 0 - https://docs.scala-lang.org/scala3/reference/metaprogramming/macros.html https://docs.scala-lang.org/scala3/reference/metaprogramming... 1 - https://scalameta.org/ https://scalameta.org/ 2 - https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless
- sfpotter 1y ago
  D is really, really good. I hope it gets more love soon. D's focus on just getting shit done, lightning builds, QOL improvements all over the place, actually good modules, templates and metaprogramming that work, simpler more regular syntax, any memory management paradigm you want, being fully batteries included, being super easy to cross compile, being able to span all the way from Python/C# slop all the way down to tight-as-you-like C code... It's an amazing language and is getting better all the time. A real C++ successor. It has become my secret weapon! Maybe I actually don't want it to blow up soon, since it gives me a huge edge on anyone stuck with C++, which gets worse every release (how slow do builds have to get before people lose it completely?).
yuppiemephisto 1y ago
Maybe too far afield, but: https://leanprover-community.github.io/lean4-metaprogramming-book/ https://leanprover-community.github.io/lean4-metaprogramming... Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.

It would be cool, except for the entire language that is available at compile-time being C++, and thus entirely unsuitable for manipulating C++ programs.

gpderetta 1y ago
Yes. It is not like C++ compilers are written in C++.

klipt 1y ago

Circle C++ does that

dataflow 1y ago
Could you show some examples?

chrisrodrigue 1y ago

...isn't that what templates were made for? Template metaprogramming in C++ is Turing-complete.

pjmlp 1y ago
Not at all, originally template metaprogramming was discovered by accident. Cannot recall any longer if the original article on the matter appeared on The C/C++ Users Journal or Dr. Dobbs. Eventually it started to get abused and the Turing completeness has been discovered. Since C++11, the approach to a more sane way to do metaprogramming with templates has been improving. Instead of tag dispatch, ADL and SFINAE, we can make use of concepts, if constexpr/eval/init, type traits, and eventually reflection, instead of the old clunky ways.
- troutwine 1y ago
  “C++ Templates are Turing Complete” by Todd L. Veldhuizen has the history of discovery, early elaboration.
  - omoikane 1y ago
    Link to paper: http://web.archive.org/web/20131101122512/http://ubietylab.net/ubigraph/content/Papers/pdf/CppTuring.pdf http://web.archive.org/web/20131101122512/http://ubietylab.n... Via "Accidentally Turing-Complete": https://news.ycombinator.com/item?id=30189780 https://news.ycombinator.com/item?id=30189780
einpoklum 1y ago
Templates are semi-accidentally Turing-complete. They were intended for writing compile-time-generic, run-time-concrete functions and types - but it turned out you could use them, along with the overload resolution mechanisms, to compute things. The Turing-completeness involves recursive use. Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less. Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)

jjmarr 1y ago

This already exists with macros, templates, and compiler extensions, if you want completely unusable/unreadable code that takes forever to build.

pjmlp 1y ago
Depends on the C++ version. With C++23 can be made relatively readable, and with the right compiler, builds within sensible timeframe.
- jjmarr 1y ago
  C++23 doesn't have full reflection yet. That's coming in C++26. I've seen the vast majority of build time in a very large C++23 project be taken up by reflection in fmtlib and magic_enum because both have to use templates (I think).
  - pjmlp 1y ago
    I didn't said it has, rather that template metaprogramming can be both readable, and with the right compiler relatively fast.
  - vitaut 1y ago
    {fmt} doesn't use reflection and is optimized for build speed using type erasure: https://vitaut.net/posts/2024/faster-cpp-compile-times/ https://vitaut.net/posts/2024/faster-cpp-compile-times/

MrRadar 1y ago

The D language basically does that. You can write D programs that evaluate D code at compile time to generate strings of new D code which you can then basically compile-time eval into your code as needed. Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages and it's easier to read than Rust macros or C++ template metaprogramming.

TOGoS 1y ago
Every time I hear about D it sounds awesome. I actually used it to prototype an image collage-composing algorithm which I then rewrote in Scala[1], and the D version might have been nicer to write. The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk. [1] One of the algorithms used by https://github.com/TOGoS/PicGrid https://github.com/TOGoS/PicGrid
AdieuToLogic 1y ago
> Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages ... Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2]. Not comparing Scala to D, just identifying a language with similar functionality. 0 - https://docs.scala-lang.org/scala3/reference/metaprogramming/macros.html https://docs.scala-lang.org/scala3/reference/metaprogramming... 1 - https://scalameta.org/ https://scalameta.org/ 2 - https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless
sfpotter 1y ago
D is really, really good. I hope it gets more love soon. D's focus on just getting shit done, lightning builds, QOL improvements all over the place, actually good modules, templates and metaprogramming that work, simpler more regular syntax, any memory management paradigm you want, being fully batteries included, being super easy to cross compile, being able to span all the way from Python/C# slop all the way down to tight-as-you-like C code... It's an amazing language and is getting better all the time. A real C++ successor. It has become my secret weapon! Maybe I actually don't want it to blow up soon, since it gives me a huge edge on anyone stuck with C++, which gets worse every release (how slow do builds have to get before people lose it completely?).

yuppiemephisto 1y ago

Maybe too far afield, but: https://leanprover-community.github.io/lean4-metaprogramming-book/ https://leanprover-community.github.io/lean4-metaprogramming... Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.