www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How does Circle's CTFE compare to D?

reply Johannes Riecken <johannes.riecken gmail.com> writes:
I've watched [Don't constexpr all the 
things](https://www.youtube.com/watch?v=NNU6cbG96M4), which is a 
talk explaining how [Cirlce](https://www.circle-lang.org/) does 
meta-programming and I found it very interesting that it looks as 
simple as I as a newbie would imagine meta-programming should be, 
i.e. it can execute any C++ function or library function at 
compile time. Here are two interesting examples:

```
int i = 0;
int f() { return ++i; }
int main()
{
     std::cout << ( meta f()) << std::endl; // Outputs 1
     std::cout << ( meta f()) << std::endl; // Outputs 2
     std::cout << i << std::endl; // Outputs 0
}
```

```
#include <fstream>
#include <iterator>
#include <string>
 meta std::ifstream f("file.txt");
 meta std::string str(std::istreambuf_iterator<char>(t),
std::istreambuf_iterator<char>());
const char file_contents[] =  string(str);
```

How does Circle's approach compare with D's (or with the vision 
of the direction of D's CTFE)? Is it likely that Circle's 
meta-programming also requires ten-thousands of lines of extra 
compiler code? I personally tend to prefer code generation over 
meta-programming, as I find that simpler to reason about and it 
works in any language, but I see the benefits of CTFE as well.
Dec 04 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 4 December 2021 at 08:43:14 UTC, Johannes Riecken 
wrote:

 I've watched [Don't constexpr all the 
 things](https://www.youtube.com/watch?v=NNU6cbG96M4), which is 
 a talk explaining how [Cirlce](https://www.circle-lang.org/) 
 does meta-programming and I found it very interesting that it 
 looks as simple as I as a newbie would imagine meta-programming 
 should be, i.e. it can execute any C++ function or library 
 function at compile time.


Circle is primarily interesting because it pushes the boundaries 
for C++, but does it allow the execution of any C++ function? I/O 
can make things very complicated as you either have to impose a 
specific compilation order or use some other ordering or 
constraining principle to avoid dependency issues or feedback 
loops. This in turns makes it impossible to accept the execution 
of any C++ function!

D's CTFE is somewhat more flexible than C++ constexpr, but C++ 
constexpr/consteval also works as an interface specification, 
meaning: if a function in a library is marked as compile time 
then you can rely on it for the future and across platforms.

The question is, what kind of language do you want? A language 
for writing small short lived self-contained programs that makes 
programming frictionless, or a language for writing larger long 
lived portable programs that depends on third party code bases 
that receive upgrades over time?

There are many really cute languages for writing small short 
lived self-contained programs, but they rarely get traction. 
(There are counter examples: PhP, Perl, …)
Dec 04 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim Grøstad 
wrote:

 D's CTFE is somewhat more flexible than C++ constexpr, but C++ 
 constexpr/consteval also works as an interface specification, 
 meaning: if a function in a library is marked as compile time 
 then you can rely on it for the future and across platforms.


Just a simple example to make this obvious, let's say you use a 
matrix library that in a later is optimized so that it uses 
cpuid() to detect the CPU type. If you CTFE this you end up 
getting the CPU type of the machine the program was compiled on! 
Not what you wanted. There are many functions that are platform 
dependent, so general CTFE is not possible for a system level 
programming language.
Dec 04 2021
prev sibling next sibling parent reply Johannes Riecken <johannes.riecken gmail.com> writes:
 Is it likely that Circle's meta-programming also requires 
 ten-thousands of lines of extra compiler code?




I see that Circle isn't open-source so that question seems 
impossible to answer.

On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim Grøstad 
wrote:

 Circle is primarily interesting because it pushes the 
 boundaries for C++, but does it allow the execution of any C++ 
 function? I/O can make things very complicated as you either 
 have to impose a specific compilation order or use some other 
 ordering or constraining principle to avoid dependency issues 
 or feedback loops. This in turns makes it impossible to accept 
 the execution of any C++ function!


Interesting point. Do you have an example for that? Going top to 
bottom seems like a good choice.


 D's CTFE is somewhat more flexible than C++ constexpr, but C++ 
 constexpr/consteval also works as an interface specification, 
 meaning: if a function in a library is marked as compile time 
 then you can rely on it for the future and across platforms.


For functions without side effects that interface specification 
would be equivalent to adding something like `static assert f(3) 
== 9` to a compile-time function f in D?


 There are many really cute languages for writing small short 
 lived self-contained programs, but they rarely get traction. 
 (There are counter examples: PhP, Perl, …)


My understanding from the talk is that Circle can compile C++, 
too, so if Sean Baxter adds a few well-specified and easily 
understandable features in a bug-free way, then I don't see the 
lack of traction being a major issue.
Dec 04 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 4 December 2021 at 13:53:27 UTC, Johannes Riecken 
wrote:

 Interesting point. Do you have an example for that? Going top 
 to bottom seems like a good choice.


Depends on what you want to do. If the compilation of one 
source-file creates a file that another source-file wants to 
read, how do you know what the order should be? A key point of 
C++ is that you can have concurrent builds.


 For functions without side effects that interface specification 
 would be equivalent to adding something like `static assert 
 f(3) == 9` to a compile-time function f in D?


In D you can test if a function is executed on compile time, but 
in C++ it is part of the function type (signature).

The key difference is that in C++ the compiler checks that a 
compile-time function is limited to a reasonable subset when it 
is defined even if it isn't used. Which is useful for library 
authors. Within an application there is no practical difference, 
really.


 My understanding from the talk is that Circle can compile C++, 
 too, so if Sean Baxter adds a few well-specified and easily 
 understandable features in a bug-free way, then I don't see the 
 lack of traction being a major issue.


It is a C++-family compiler, so you are right, it could pick up 
some interest for that reason alone! I guess some would use it if 
it was open source. I personally wouldn't as C++ does not need 
more complexity and features that does not match the rest of the 
language. (What was Sutter thinking when he came up with the 
syntax for "inspect"/"is"/"as"?)

This is something D needs to take advantage of. KISS! (Keep It 
Simple Stupid ;^)
Dec 04 2021
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 4 December 2021 at 08:43:14 UTC, Johannes Riecken 
 wrote:

 [...]


 Circle is primarily interesting because it pushes the 
 boundaries for C++, but does it allow the execution of any C++ 
 function? I/O can make things very complicated as you either 
 have to impose a specific compilation order or use some other 
 ordering or constraining principle to avoid dependency issues 
 or feedback loops. This in turns makes it impossible to accept 
 the execution of any C++ function!

 ...


Yes it does, have fun with Circle.

https://github.com/seanbaxter/circle/blob/master/embed/embed.md
Dec 04 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Saturday, 4 December 2021 at 14:00:22 UTC, Paulo Pinto wrote:

 On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 4 December 2021 at 08:43:14 UTC, Johannes Riecken 
 wrote:

 [...]


 Circle is primarily interesting because it pushes the 
 boundaries for C++, but does it allow the execution of any C++ 
 function? I/O can make things very complicated as you either 
 have to impose a specific compilation order or use some other 
 ordering or constraining principle to avoid dependency issues 
 or feedback loops. This in turns makes it impossible to accept 
 the execution of any C++ function!

 ...


 Yes it does, have fun with Circle.

 https://github.com/seanbaxter/circle/blob/master/embed/embed.md


That tone didn't sound very positive

What do you think about Circle?
I personally dislike the ` meta` everywhere :(
Plus, C++ syntax D:
Dec 04 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 December 2021 at 14:44:10 UTC, Tejas wrote:

 On Saturday, 4 December 2021 at 14:00:22 UTC, Paulo Pinto wrote:

 On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 4 December 2021 at 08:43:14 UTC, Johannes 
 Riecken wrote:

 [...]


 Circle is primarily interesting because it pushes the 
 boundaries for C++, but does it allow the execution of any 
 C++ function? I/O can make things very complicated as you 
 either have to impose a specific compilation order or use 
 some other ordering or constraining principle to avoid 
 dependency issues or feedback loops. This in turns makes it 
 impossible to accept the execution of any C++ function!

 ...


 Yes it does, have fun with Circle.

 https://github.com/seanbaxter/circle/blob/master/embed/embed.md


 That tone didn't sound very positive

 What do you think about Circle?
 I personally dislike the ` meta` everywhere :(
 Plus, C++ syntax D:


You are reading more than what it is there.

I think Circle is the right approach instead of constepxr, 
constinit, consteval, and whatever might still come up, like 
reflect.

C++ syntax, regardless how obtuse it might be, is available to me 
on my work computers as standard IT image.
Dec 04 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 4 December 2021 at 15:35:20 UTC, Paulo Pinto wrote:

 I think Circle is the right approach instead of constepxr, 
 constinit, consteval, and whatever might still come up, like


These are constraints that allows you to catch bugs and 
inefficiencies at compile time.

Circle does not offer a replacement for constraints?
Dec 04 2021