Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

[FeepingCreature]

On Sunday, 18 April 2021 at 04:41:44 UTC, Ola Fosheim Grostad 
wrote:
> On Sunday, 18 April 2021 at 00:38:13 UTC, Ali Çehreli wrote:
>> I heard about safety issues around allowing full I/O during 
>> compilation but then the following points kind of convinced me:
>>
>> - If I am compiling a program, my goal is to execute that 
>> program anyway. What difference does it make whether the 
>> program's compilation is harmful vs. the program itself.
>
> I dont buy this, you can execute the code in a sandbox.
>
> Compilation should be idempotent, writing to disk/databases 
> during compilation breaks this guarantee.
>
> I would not use a language that does not ensure this.
>

This is a social issue more than a technical one. The framework 
can help, by limiting access to disk and URLs and allowing 
tracing and hijacking, but ultimately you have to rely on code to 
not do crazy things. And right now in D we just push this 
complexity out of the language and into the build system, because 
if you don't let people do crazy things, they just do crazy and 
also horribly hacky things instead. (*Cough* gen_ut_main *cough*.)

In my opinion, the design approach should be to "default open, 
then restrict", rather than "default closed, then relax." This 
requires a certain willingness to break people's workflow, but if 
you default closed, you'll never get over your preconceptions, 
because you have to be able to do crazy things to find out what 
works and what doesn't, and you can't gather experience with what 
people actually want to do and how it works in practice if you 
lock things down from the start. In other words, I see no reason 
why "make one to throw it away" shouldn't apply  to languages.

Maybe we will decide one day to limit recursion for templates and 
CTFE, for instance, but if we do, it will be because of the 
experiences we gathered with unrestricted templates and the 
impact on compile times - if D had decided from day one to keep 
templates limited, we'd never have the wealth of experience and 
frameworks and selling points that D has with metaprogramming. 
You have to let people show you what they want to do and what 
comes of it, and you can't do that if you don't extend them 
enough rope to tangle themselves and their projects up first. 
There has to be a willingness to try and fail and backtrack.

Most of my annoyances with D are issues where D isn't willing to 
take an additional step even though it would be technically very 
feasible. No implicit conversion for user-defined types, no 
arbitrary IO calls in CTFE, no returning AST trees from CTFE 
functions that are automatically inserted to create macros, and 
of course the cumbersome specialcased metaprogramming for type 
inspection instead of just letting us pass a type object to a 
ctfe function and calling methods on it. If some new language 
will overtake D (cx¹, fingers crossed!), it will be because of 
this design conservatism as much as any technological restriction 
in the frontend.

¹ I have a language, by the way! :) 
https://github.com/FeepingCreature/cx , but it's pre-pre-alpha. 
Native CTFE and macros are a beautiful thing though.