I believe our documentation's current use of the terms "compile time" and "runtime" is confusing and often misleading. Here is a proposed new direction. Once we've discussed it a bit here, I have a meta-question: is this worth an RFC, or should I just PR the doc changes?
example 1 of current confusion
The manual says, "The compiler must be able to evaluate the expression in a constant declaration at compile time."
Now consider the following code:
static:
var v = 3.1415
echo v
static:
var v = 3.1415
const pi = v
echo pi
How about this code?
static:
const pi = block:
var v = 3.1415
v
echo pi
example 2 of current confusion
The manual says, "A static error is an error that the implementation detects before program execution." Contrast that with a subsequent statement, "A checked runtime error is an error that the implementation detects and reports at runtime." So, how about the following code:
static:
var data: array[3, int]
proc store(loc: int, value: int) =
data[loc] = value
for i in 0 .. 3:
store(i, 42)
stack trace: (most recent call last)
error_in_static_block.nim(6) error_in_static_block
error_in_static_block.nim(4) store
error_in_static_block.nim(4, 9) Error: index out of bounds
proposed solution
We use "compile time" to talk about everything that happens during compilation -- including compile-time execution.
We use "runtime" to talk about everything that happens when running the output of the compiler (such as a binary).
We distinguish between "semantic analysis" (or simply “analysis”) and “execution”.
We can unambiguously talk about "semantic analysis" (or simply “analysis”), since that only happens at compile time. But we have to be careful about when to simply say "execution", versus when to be more specific by saying "compile-time execution" or "runtime execution".
We say that at compile time, we interleave semantic analysis and execution. For example, we may do semantic analysis on a macro, semantic analysis on code that invokes the macro, execution of the macro, and then semantic analysis on the invoking code again after macro expansion.
example 1 with the proposed solution
The manual could now say something like this:
The expression in a constant declaration can only use language features that are supported for compile-time execution, and can only depend on literal values, previously declared constants, and previously declared procs, macros, and templates. It can only depend on procs whose bodies meet these same requirements.
example 2 with proposed solution
The manual could now say things like this:
A static error is an error that the compiler detects during semantic analysis.
A checked execution error is an error that is detected during code execution, whether at compile time or at runtime.
my meta-question
Is this worth an RFC, or should I just informally seek a consensus (such as here in the forum) and then PR the doc changes?
You recommend changing compile time to analysis?, that sounds even more confusing.
CT FFI may not be a primitive literal value, or does not feel like it.
I feel that for JavaScript and NimScript runtime makes more sense that execution, no one says executing on the browser.
I'm not actually proposing changing "compile time" to "analysis". I'm still proposing using the term "compile time" to talk about everything that happens during compilation. I'm just proposing that when we talk about what happens at compile time, we make a careful distinction between "semantic analysis" (or simply "analysis") and compile-time execution.
Athough I agree that "execution" is a far less common term in a browser setting than "runtime", I think it would be very helpful to use the same term for code execution at compile time and at runtime. Another available term would be "evaluation", but truly nobody says "evaluated in the browser". I see 320,000 Google hits for "executed in the browser".
Here's a sentence from the first few paragraphs of V8's documentation:
V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs.