circle

I think reading through all the examples https://github.com/seanbaxter/circle/blob/master/examples/RE... makes it clear that the author has put quite a deal of thought into how these features make it easier to write clear, understandable and maintainable code. Even the example you point to goes to say: "Let's use the integrated interpreter to define a useful build tool. Software is the subject of constant revisions, and it's useful to mark a distributable with the exact version of the source-control archive it was built with." It's clear (to me) that the developer is not advocating using terminal input in the middle of a build. I haven't used terminal input since I was a child; I don't think the developer expects anyone to take that as a serious example.

>But, I think this trend might lead to extremely hard to read code, and there is a good chance that this hard-to-read code will be treated as some black box/voodoo. This already happens with metaprogramming in C++. See e.g. the source of the Boost Preprocessor library. Circle just makes this code a bit easier to read. Even code using the library: compare the compile-time Duff's device generation in https://www.boost.org/doc/libs/1_72_0/libs/preprocessor/doc/... to that in https://github.com/seanbaxter/circle/blob/master/examples/RE... .

Zig seems to have arbitrary compile-time code evaluation, but not the kind of AST generation you see here[1]. Nim macros seem to be a closer analogue[2]. [1]: https://github.com/seanbaxter/circle/blob/master/gems/rpn.md... [2]: https://nim-lang.org/docs/macros.html

See also https://github.com/seanbaxter/circle for an up to date list of features, the compiler now also supports match expressions, list comprehensions and more.