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

Cache inferred types for sub expression #4

Open
hagl opened this issue Jan 10, 2022 · 0 comments
Open

Cache inferred types for sub expression #4

hagl opened this issue Jan 10, 2022 · 0 comments

Comments

@hagl
Copy link
Owner

hagl commented Jan 10, 2022

When importing an expression, the imported expression needs to be type-checked before it is included into the importing expression. When this expression is imported itself it will also be type-checked and in that process the first expression will be typechecked again.

Consider the following scenario

  A.dhall  --> B.dhall --> C.dhall       (where x --> y stands for x imports y)

The resolution phase will do the following steps:

Aᵣ = resolve A.dhall
  B = import B.dhall
  Bᵣ = resolve B.dhall
    C = import C.dhall
    Cᵣ = resolve C
    type-check Cᵣ
  type check Bᵣ (which now includes Cᵣ)
...

This gets worse the deeper the nesting of imports is.
A file might also be included multiple times through different paths. While the imported & type-checked expression is cached during one resolution phase, the included expression will still be type-checked again as part of the including expression.

For example tests/type-inference/success/preludeA.dhall includes around 100 files (all of prelude). And especially the more complex expression in the JSON, YAML and XML folders include a lot of the basic expressions from String, List and Map folders over and over again.

This causes the type-checking of this file to take multiple hours at the moment.

Storing the resolved type of a sub-expression inside the AST should greatly optimize this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant