Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Deno compile-time functions CTFE #7359

Closed
jadbox opened this issue Sep 5, 2020 · 2 comments
Closed

Idea: Deno compile-time functions CTFE #7359

jadbox opened this issue Sep 5, 2020 · 2 comments
Labels
cli related to cli/ dir declined thank you, but respectfully declined suggestion suggestions for new features (yet to be agreed)

Comments

@jadbox
Copy link

jadbox commented Sep 5, 2020

CTFE = Compile time function execution
https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe

In Rust, they are called Constant Expressions:
https://doc.rust-lang.org/reference/const_eval.html

I think what I'm fishing for here is a way for Deno to provide a [pre] TS compile-time hook (or on hot reload): i.e. a special app entry-point will get called prior to the application starting or reloading. For example, our app may look like:

data.json

{
  "hello": "world"
}

index.ts:

// special compile-time function that runs and sets 
function hook_prebuild() {
 const data = await fetch('./data.json');
 process.build.mydata = data; // process.build would be a new special global for prebuilt data
}

console.log("result: ", process.build.mydata);

I think this might be valuable to the Deno ecosystem as it reduces the need for a basic build system for many common cases, which are mainly frontrunning data loading or data generation. I'd imagine this would would by calling the TS compiler twice to first run the prebuild/CTFE hook, stash the resulting data somehow, and reuse it for the regular TS project compile.

Now what would be REALLY interesting is if Deno could statically inject that data into the second phase of the regular TypeScript compilation. If TypeScript can be aware of the raw values used in the first compile, you can use the upcoming TS 4.1 template literal types (https://twitter.com/danvdk/status/1301707026507198464) to build types based on the static data generated in the first prebuild step!

The end result is you could write a TS project fetch a json file, generate a string to represent it's structure, and then use 4.1's template literal to have strict type generation of that json file available for regular type validation use, but that type is being generated via a previous compile-time/CTFE hook. Deno could allow TypeScript to do something that it doesn't wish to do for itself as a tool (microsoft/TypeScript#26534 and microsoft/TypeScript#15761)... this may fill in a missing piece of the toolchain that would be a treasured expansion of language's overall capabilities.

If you're still not sold, see what SQLx does for Rust using Const Evalutions (CTFE). It's able to both query strings at compile time -and- generate strict types for query results! https://github.com/launchbadge/sqlx

@kitsonk
Copy link
Contributor

kitsonk commented Sep 5, 2020

I am personally not convinced that something like this would be beneficial at all. We are doing everything we can to cut out the time between reading TypeScript and injecting in the isolate. We only "compile" TypeScript because we have to, it is a necessary evil. Ultimately I don't think we would want to deal with the complexity of the semantics of something like that and maintain it. It would require creating a sandbox at compile time to execute some code, which we would have to pick out of the TypeScript, then find a way to serialise it, cache it, and rehydrate it back. I think it would end up being a lot slower, and for a lot of added complexity.

Ultimately, I think the best option for something like this is #1739, which would allow people to create workers that would be able to do whatever processing they want to a file and emit JavaScript which could be run.

Also, I think there is more upside in something like that for a truly compiled language like Rust. For Deno, I suspect we would maybe get a little bit better performance than we have now by something like #3335.

@kitsonk kitsonk added cli related to cli/ dir suggestion suggestions for new features (yet to be agreed) declined thank you, but respectfully declined labels Nov 17, 2020
@kitsonk
Copy link
Contributor

kitsonk commented Nov 17, 2020

At this point, this would be too much complexity without significant benefit. Respectfully closing.

@kitsonk kitsonk closed this as completed Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir declined thank you, but respectfully declined suggestion suggestions for new features (yet to be agreed)
Projects
None yet
Development

No branches or pull requests

2 participants