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.

Sign up for GitHub

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

Jump to bottom

Per-module compilation #2392

Closed
janmasrovira opened this issue Sep 26, 2023 · 0 comments · Fixed by #2468
Closed

Per-module compilation #2392

janmasrovira opened this issue Sep 26, 2023 · 0 comments · Fixed by #2468
Labels
enhancement New feature or request pending-review refactor

Comments

@janmasrovira
Copy link
Collaborator

Things to store for each module:

  1. Hash of the source to decide if this info needs to be recomputed.
  2. Export info. For each symbol:
    1. Name, kind, fixity, def location, builtin info, termination (bool).
    2. For names with fixity, store only the Fixity, not the DefPrec integer.
    3. For fixity names, the full definition.
    4. The name id is a triple with a hash of the package name and the top module name and local name id.
    5. The type in internal.
    6. Translation to core. After to-eval transformations.
    7. Definition in Internal if it can be normalized (type synonyms).
    8. The named arguments signature if it has one. Record fields should also use this.
    9. For inductive types, is it a trait?
    10. For functions, is it an instance?
    11. Pragmas.
  3. Highlight info. Keywords: location. Identifiers: kind, location, type and judoc. We don't need the full source.
  4. (Future) Full source could be useful:
    1. Jump to definition inside of the compiled module.
    2. Generate html.
@lukaszcz lukaszcz mentioned this issue Oct 24, 2023
Merged
18 tasks
@lukaszcz lukaszcz changed the title Per-module compilation (Draft) Per-module compilation Nov 22, 2023
janmasrovira pushed a commit that referenced this issue Dec 30, 2023
@lukaszcz
Per-module compilation (#2468)
75bce8f 
* Closes #2392 

Changes checklist
-----------------
* [X] Abstract out data types for stored module representation
(`ModuleInfo` in `Juvix.Compiler.Store.Language`)
* [X] Adapt the parser to operate per-module
* [X] Adapt the scoper to operate per-module
* [X] Adapt the arity checker to operate per-module
* [X] Adapt the type checker to operate per-module
* [x] Adapt Core transformations to operate per-module
* [X] Adapt the pipeline functions in `Juvix.Compiler.Pipeline`
* [X] Add `Juvix.Compiler.Pipeline.Driver` which drives the per-module
compilation process
* [x] Implement module saving / loading in `Pipeline.Driver`
* [x] Detect cyclic module dependencies in `Pipeline.Driver`
* [x] Cache visited modules in memory in `Pipeline.Driver` to avoid
excessive disk operations and repeated hash re-computations
* [x] Recompile a module if one of its dependencies needs recompilation
and contains functions that are always inlined.
* [x] Fix identifier dependencies for mutual block creation in
`Internal.fromConcrete`
- Fixed by making textually later definitions depend on earlier ones.
- Now instances are used for resolution only after the textual point of
their definition.
- Similarly, type synonyms will be unfolded only after the textual point
of their definition.
* [x] Fix CLI
* [x] Fix REPL
* [x] Fix highlighting
* [x] Fix HTML generation
* [x] Adapt test suite
@paulcadman paulcadman mentioned this issue Mar 9, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request pending-review refactor
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Per-module compilation anoma/juvix
1 participant
@janmasrovira