CTFE & code generators based on PEG grammars?

[Alex]

On Saturday, 6 April 2019 at 14:59:18 UTC, ag0aep6g wrote:
> On 06.04.19 16:19, Alex wrote:
>> That is CTFE is CT RTFE where runtime functions are executed 
>> at compile time when the inputs are CT.
>
> You may have the right idea, but the last part of that sentence 
> is wrong/misleading. CTFE happens when the result is required 
> at CT. The inputs must be available at CT, but that alone 
> doesn't trigger CTFE.
>
> Examples:
>
> ----
> bool f(string s) { return __ctfe; }
> void main()
> {
>     import std.stdio: readln;
>     enum x = f("foo"); /* CTFE */
>     enum y = f(readln()); /* error, because "readln" can't be 
> CTFEd */
>     auto z = f("foo"); /* not CTFE */
> }
> ----


readlin is not a CT function. You misinterpreted what I said.

The function I am talking about is the runtime function(That is a 
function that can be run at RT) is to be CTFE'ed.

readln is not to be CTFE'ed.

There is nothing I said that contradicts what you wrote. The 
input to f, the RT function to be CTFE'ed cannot be CTFE'ed 
because one of it's inputs is not known at CT, that input is 
readln, which is another RT that could be CTFE'ed but it cannot 
because it's input is not known at CT.


It is obvious that if any RT function(as opposed to a CT function 
which obviously is ran at CT. CT functions are pure templates) is 
CTFE'able only if all it's inputs are CTFE'able. This creates a 
chain reaction. Your chain fails at readln.

Again, you misinterpreted what I said.

I will be clear once more so we are not in disagreement:

>> That is CTFE is CT RTFE where runtime functions are executed 
>> at compile time when the inputs are CT.

CTFE is compile time runtime function execution. That is, it 
exectues *RUNTIME functions* at compile time. I'm not saying that 
it executes all runtime functions at compile time, I'm saying it 
executes runtime functions. THat is PRECISELY what it does. It 
takes a function that is designed or to be run at RT(as far as 
the compiler's semantics see it) and it executes it. That, of 
course, may fail, but that is irrelevant. The CTFE engine 
executes RT functions.

If you think "Well, it will then executes readln()", yes, it 
does... but it fails and so the output of readln is not known at 
CT and the chain breaks which is why I said the inputs have to be 
CT, the input to readln is CT, the input to f is not CT since the 
output of readln is not CT. (readln actually has a hidden input 
that is not known at CT, which is the keyboard).


If you think of it the way I have said and understand what it 
means then it is much easier to understand CTFE because you 
really are just doing "normal" programming of RT functions but 
you just execute them at CT if possible(and the possibility 
simply is if the inputs are known at CT).

By thinking this way there is really no confusion with CTFE, 
everyone that programs can program in CTFE without any 
complications about meta programming. CTFE is not meta 
programming(but one can use meta programming with it for more 
complex work). CTFE programming is RT programming but where one 
can optimize before RT. It becomes very simple to think about 
rather than trying to pretend there is some complex distinction.