fuzion
fuzion copied to clipboard
compile_time effect
An effect compile_time could be nice:
compile_time(T type, f ()->T) T : simple_effect => f.call
This way we could enforce evaluation of code at compile time or raise an error if not possible.
comptime is a loved feature of Zig, we should think about how such a feature would fit into Fuzion and what its semantics should be. An effect is only one way to provide this, we should first check what we expect from this feature. What I would like to have
- compilation time evaluation should be the default for code operating on input that is compile time constant, there should be no need for a
comptimemarker - it should be possible to debug code that is evaluated at compile time, i.e., adding any effect that performs debug output or provides hooks for run-time analysis should be possible, even if the code then could no longer be evaluated at compile time
- compile time evaluation should work with certain effects like a local mutate effect
- the halting problem prevents us from automatically doing
comptime, so maybe thecomptimemarker could be interpreted as a user annotation telling us: This code does terminate, trust me, bro! - what should happen if compile time evaluation is not possible, e.g. because a
say "hi"was added in the code? Compilaton failure, a warning, or nothing? - is there any benefit in marking side-effect free code as compile-time as in
add(a, b i32) ! comptime => a+b? Or should the absence of any effects imply this? - should a
comptimemarker have any clearly defined semantics (and what should these semantics be?) or be a mere hint for the compiler that might be respected or ignored?
For now, I would first spend much more work into support for compile-time evaluation of intrinsics and code with simple control flow and then see what might be most useful for such an api.
The API itself could then be
- an effect as suggested
- or just a special version of the
idfunction that checks that the value is a compile time constant. - a feature modifier
- other?