3 ms·

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be comput

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be computed ahead of time? At least in the simple cases such as the square example, which are I believe quite common, that would work. Maybe still add an annotation to make sure the compiler will do what the user expects, because humans are terrible compilers after all. Because the "footgun" here is really that when using macros we are switching languages and strategies - in one case it's eager evaluation, and in the other is sort of like lazy evaluation.

throwawaymaths 3y ago
Do you mean in zig? It's possible to do arbitrary, bounded computation (compiler quits if you expend "too many tokens") at comptime in zig, unless there is strange statefulness. This is sensible since you want changes in, e.g. your code tree to taint compiled resources. If your code can go read from the filesystem in an untracked way, you break the incremental compilation model.
- astrobe_ 3y ago
  This was sort of a general question, although Zig confused me a bit by placing the annotation at the call site rather than on the function declaration. I guess this choice was made to keep compilation times under control.
  - throwawaymaths 3y ago
    A function should not have to be labelled as comptime to be run at comptime. There are cases when you might want to run the same function at comptime as at runtime (for example, if you want to do a thing with algorithm X but cache the result for a series of trivial cases as a lookup table). Putting it at the callsite is more explicit actually and for example generating precompiled arrays clearly ties comptimeness to the actual artifact created instead of making it inferred from the signature of the function (which may be very far away in code)
flohofwoe 3y ago
C/C++ compilers will do this when optimization is enabled (I guess the reason that's not done without optimization is to preserve "debuggability"). Notice how the add() function is completely 'disolved' into its result '5' here: https://www.godbolt.org/z/q98svvacW https://www.godbolt.org/z/q98svvacW (the main difference to comptime is that this guarantees that the code is resolved at compile time, and if that's not possible you'll get an error). The big downside of comptime is that it isn't debuggable, apart from what's essentially 'printf debugging' via the @compileError builtin).
- mike_hearn 3y ago
  Graal's native-image tool also does a form of this. The compiler actually executes parts of your program at compile time, but it's real execution so you can theoretically do anything. The heap data that's generated is then persisted into the program. You can debug such code just like normal code by just running it on HotSpot instead.
- menaerus 3y ago
  Not only the work of the C/C++ optimizer but the exact reason why C++ constexpr was designed - to compute expressions during the compile-time iff all its dependants can be resolved during the compile time. If they don't it's still cool, they behave as a normal runtime function.

throwawaymaths 3y ago

Do you mean in zig? It's possible to do arbitrary, bounded computation (compiler quits if you expend "too many tokens") at comptime in zig, unless there is strange statefulness. This is sensible since you want changes in, e.g. your code tree to taint compiled resources. If your code can go read from the filesystem in an untracked way, you break the incremental compilation model.

astrobe_ 3y ago
This was sort of a general question, although Zig confused me a bit by placing the annotation at the call site rather than on the function declaration. I guess this choice was made to keep compilation times under control.
- throwawaymaths 3y ago
  A function should not have to be labelled as comptime to be run at comptime. There are cases when you might want to run the same function at comptime as at runtime (for example, if you want to do a thing with algorithm X but cache the result for a series of trivial cases as a lookup table). Putting it at the callsite is more explicit actually and for example generating precompiled arrays clearly ties comptimeness to the actual artifact created instead of making it inferred from the signature of the function (which may be very far away in code)

flohofwoe 3y ago

C/C++ compilers will do this when optimization is enabled (I guess the reason that's not done without optimization is to preserve "debuggability"). Notice how the add() function is completely 'disolved' into its result '5' here: https://www.godbolt.org/z/q98svvacW https://www.godbolt.org/z/q98svvacW (the main difference to comptime is that this guarantees that the code is resolved at compile time, and if that's not possible you'll get an error). The big downside of comptime is that it isn't debuggable, apart from what's essentially 'printf debugging' via the @compileError builtin).

mike_hearn 3y ago
Graal's native-image tool also does a form of this. The compiler actually executes parts of your program at compile time, but it's real execution so you can theoretically do anything. The heap data that's generated is then persisted into the program. You can debug such code just like normal code by just running it on HotSpot instead.
menaerus 3y ago
Not only the work of the C/C++ optimizer but the exact reason why C++ constexpr was designed - to compute expressions during the compile-time iff all its dependants can be resolved during the compile time. If they don't it's still cool, they behave as a normal runtime function.