mirror of
https://github.com/anoma/juvix.git
synced 2024-07-14 19:30:34 +03:00
Juvix empowers developers to write code in a high-level, functional language, compile it to gas-efficient output VM instructions, and formally verify the safety of their contracts prior to deployment and execution.
6fcc9f21d2
Currently formatting a project is equivalent to running `juvix format`
on each individual file. Hence, the performance is quadratic wrt the
number of modules in the project. This pr fixes that and we now we only
process each module once.
# Benchmark (1236% faster 🚀)
Checking the standard library
```
hyperfine --warmup 1 'juvix format --check' 'juvix-main format --check'
Benchmark 1: juvix format --check
Time (mean ± σ): 450.6 ms ± 33.7 ms [User: 707.2 ms, System: 178.7 ms]
Range (min … max): 396.0 ms … 497.0 ms 10 runs
Benchmark 2: juvix-main format --check
Time (mean ± σ): 6.019 s ± 0.267 s [User: 9.333 s, System: 1.512 s]
Range (min … max): 5.598 s … 6.524 s 10 runs
Summary
juvix format --check ran
13.36 ± 1.16 times faster than juvix-main format --check
```
# Other changes:
1. The `EntryPoint` field `entryPointModulePath` is now optional.
2. I've introduced a new type `TopModulePathKey` which is analogous to
`TopModulePath` but wihout location information. It is used in hashmap
keys where the location in the key is never used. This is useful as we
can now get a `TopModulePathKey` from a `Path Rel File`.
3. I've refactored the `_formatInput` field in `FormatOptions` so that
it doesn't need to be a special case anymore.
4. I've introduced a new effect `Forcing` that allows to individually
force fields of a record type with a convenient syntax.
5. I've refactored some of the constraints in scoping so that they only
require `Reader Package` instead of `Reader EntryPoint`.
6. I've introduced a new type family so that local modules are no longer
required to have `ModuleId` from their type. Before, they were assigned
one, but it was never used.
# Future work:
1. For project-wise formatting, the compilation is done in parallel, but
the formatting is still done sequentially. That should be improved.
|
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| app | ||
| assets | ||
| bench | ||
| bench2 | ||
| examples | ||
| gnuplot | ||
| include | ||
| juvix-stdlib@00f6f503db | ||
| licenses | ||
| runtime | ||
| scripts | ||
| src | ||
| test | ||
| tests | ||
| .clang-format | ||
| .github_changelog_generator | ||
| .gitignore | ||
| .gitmodules | ||
| .hlint.yaml | ||
| .pre-commit-config.yaml | ||
| cabal.hie.yaml | ||
| cabal.project | ||
| cabal.project.freeze | ||
| CHANGELOG.md | ||
| cntlines.sh | ||
| CONTRIBUTING.md | ||
| justfile | ||
| LICENSE.md | ||
| Makefile | ||
| package.yaml | ||
| README.md | ||
| stack.hie.yaml | ||
| stack.yaml | ||
Juvix
| CI Status |
|---|
|
|
|
|
| Codebase |
|
|
|
This repository is specifically dedicated to the compiler of the Juvix programming language.
For any Juvix-related inquiries, we strongly advise visiting the following resources.
Our documentation offers an in-depth understanding of the Juvix programming language. It encompasses a language reference, examples, blog posts, and numerous other resources to facilitate effective use of Juvix.