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

[FeepingCreature]

On Monday, 19 April 2021 at 08:46:05 UTC, Ola Fosheim Grøstad 
wrote:
> I think the downsides are conceptual and technical, not social. 
> If you can implement a version counter then you get all kinds 
> of problems, like first compilation succeeding, then the second 
> compilation failing with no code changes. Also, you can no 
> longer cache intermediate representations between compilations 
> without a rather significant additional machinery. It is better 
> to do this in a more functional way, so you can generate a 
> file, but it isn't written to disk, it is an abstract entity 
> during compilation and is turned into something concrete after 
> compilation.
>

> So, anything that can be deduced from the input is fair game, 
> but allowing arbitrary I/O is a completely different beast, 
> compilation has to be idempotent. It should not be possible to 
> write a program where the first compilation succeeds and the 
> second compilation fails with no code changes between the 
> compilation executions. Such failures should be limited to the 
> build system so that you can quickly correct the problem.
>
> IMHO, a good productive language makes debugging easier, faster 
> and less frequently needed. Anything that goes against that is 
> a move in the wrong direction.

Right, I agree with all of this. I just think the way to get to 
it is to first allow everything, and then in a second step pare 
it down to something that does what people need while also being 
monitorable. This is as "simple" as merging every IO call the 
program does into its state count.

(For my lang, I just go and hash every part of the program during 
compilation. So caching works on the basis of what actually goes 
into the binary.)

But my view is, you have those issues anyways! You need to run a 
caching dub server, and you need to run it on a Docker image, and 
you need to pretty much mirror every upstream package that your 
Docker install pulls in, *anyways.* You can't escape the vagaries 
of the build environment changing under you by limiting the 
language. And everything you keep out of the language - IO, 
downloads, arbitrary commands whose output is relevant - the rest 
of your build environment usually does regardless. (And it will 
mess you up at the first, slightest provocation. Bloody Ubuntu 
and its breaking changes in patch releases...) So my view is the 
other way around - make the language the single point of contact 
for *all of that stuff*, make CTFE powerful enough to hash static 
libraries and process header files live during compilation, so 
you can pull as much of the complexity as possible into the 
controlled environment of the compiler. And then when you know 
what you need there, take a step back and frameworkize it, so you 
can do change detection inside your single build system. You 
can't get the entire OS on board, but you can maybe get all or 
most of your language library developers on board.

Anyways, even agreeing that you're right, "look, we tried it and 
it didn't work, in fact it was a disaster, see discussions here 
and here, or download version 2019-03-06 nightly to try how it 
went" is just inherently a stronger argument.

>> 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
>
> That's ok for a prototype, but not for a production language.
>

I think most long-term successful languages straddle a line here. 
For instance, looking at Rust, the use of nightly and stable 
channels allows the language to experiment while also keeping a 
guarantee that once it commits to a feature enough to merge it 
into stable, it won't change "overnight". D is trying to do a 
similar thing with DIPs and preview flags and deprecations, but 
the jury's still out on how well it's working - or if not, if D 
can make it work. At any rate, with a lot of features like 
implicit conversions, I think people would find that they're 
harmless and highly useful if they'd just try them for a while.