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

Merge Ezno runtime definitions with existing TS definition files #121

Open
kaleidawave opened this issue Mar 3, 2024 · 3 comments
Open
Assignees
Labels
checking Issues around checking enhancement New feature or request needs-investigation Further information is requested

Comments

@kaleidawave
Copy link
Owner

kaleidawave commented Mar 3, 2024

Currently the checker is built around definitions from this file

https://github.com/kaleidawave/ezno/blob/main/checker/definitions/overrides.d.ts

To support more of the runtime (as highlighted in #118), the checker should be able to use definitions from the TypeScript repository (such as es5.d.ts) to provide the same type coverage. As can be seen in overrides.d.ts, Ezno has some extended definitions to provide better information to the checker. What should be done is to create a tool (code mod / code modification) (similar to code_blocks_to_script.rs that parses es5.d.ts but selectively overwrites with definitions in overrides.d.ts to produce a final definition file build.

Warning

#120 (increasing the count of types and layout) is really needed to support the scale of es5.d.ts

@kaleidawave kaleidawave added enhancement New feature or request needs-investigation Further information is requested checking Issues around checking labels Mar 3, 2024
@kaleidawave
Copy link
Owner Author

Some thinking on es5.d.ts

Also I don't quite know the status of how much of es5.d.ts Ezno currently supports. For example the features:

  • rest parameters
  • optional parameters (I think but, no tests?)
  • overloading (TODO write up issue)
  • Mapped types (TODO issues for the last two maybe)
    • Record
    • Pick
    • Omit
  • readonly properties
  • Symbols

Taking a flick through some things

  • Not all overloading needs to be considered
  • Some helpers like Awaited might not be needed initially (or implemented in other ways)
  • what to do for intristic types
  • *X* and *X*Constructor types can be merged (as the definitions now use classes)
  • Things like Math need @Constant decorators on most methods (but Math.random() needs @InputOutput
  • Console needs @InputOutput on most methods

@CharlesTaylor7
Copy link
Contributor

CharlesTaylor7 commented Apr 14, 2024

What does the @Constant decorator mean?
Does it mean that the function can be safely run at compile time?

@kaleidawave
Copy link
Owner Author

@Constant marks a function or method as having its effect as FunctionEffect::Constant which yes principally means its return type is fixed and can be calculated at compile time IF its inputs are literals. This calculating is done in the checker/src/features/constant_functions.rs file.

For example here Math.sqrt is a function with constant effects under identifier sqrt

@Constant
static sqrt(x: number): number;

and if its input are known and literal (for example 16), then it can be calculated in Rust
"sqrt" => num.sqrt(),

which is how you get the errors here.

It is a slightly bit gimmicky, it can catch against some always true cases but only when you are dealing with constants. It is still WIP, some cases are changing, it is slightly abused for the print_type and other helper functions for development. I should write up some more documentation for it and its other kinds!!

(If there is no identifier passed to the decorator it just sets the constant identifier as the name of the function method it is under)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
checking Issues around checking enhancement New feature or request needs-investigation Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants