* Closes#2032.
* Adds the `juvix dev core normalize` command.
* Adds the `:n` command in JuvixCore REPL.
* Adds the `--normalize` flag to `juvix dev core read` and `juvix dev
core from-concrete`.
* Adds `pipeline-normalize` which denotes pipeline steps necessary
before normalization.
* Adds normalization tests in `tests/VampIR/positive/Core`.
* Closes#1989
* Adds optimization phases to the pipline (specified by
`opt-phase-eval`, `opt-phase-exec` and `opt-phase-geb` transformations).
* Adds the `-O` option to the `compile` command to specify the
optimization level.
* Functions can be declared for inlining with the `inline` pragma:
```
{-# inline: true #-}
const : {A B : Type} -> A -> B -> A;
const x _ := x;
```
By default, the function is inlined only if it's fully applied. One can
specify that a function (partially) applied to at least `n` explicit
arguments should be inlined.
```
{-# inline: 2 #-}
compose : {A B C : Type} -> (B -> C) -> (A -> B) -> A -> C;
compose f g x := f (g x);
```
Then `compose f g` will be inlined, even though it's not fully applied.
But `compose f` won't be inlined.
* Non-recursive fully applied functions are automatically inlined if the
height of the body term does not exceed the inlining depth limit, which
can be specified with the `--inline` option to the `compile` command.
* The pragma `inline: false` disables automatic inlining on a
per-function basis.
Currently we typecheck and check formatting of juvix examples. However
the make target redundantly traverses the juvix files within the
.juvix-build directory contained in each project (which has been created
during previous tests).
This commit cleans the .juvix-build directories before performing each
of these checks.
This pr includes some small adjustments to the Core prettyprinter.
Currently printing core code usually generates very long lines. In order
to improve that, now let and lambda bodies are printed in the following
line if they do not fit in the current line.
- Closes#2039
- Closes#2055
- Depends on #2053
Changes in this pr:
- Local modules are removed (flattened) in the translation abstract ->
internal.
- In the translation abstract -> internal we group definitions in
mutually recursive blocks. These blocks can contain function definitions
and type definitions. Previously we only handled functions.
- The translation of Internal has been enhanced to handle these mutually
recursive blocks.
- Some improvements the pretty printer for internal (e.g. we now print
builtin tags properly).
- A "hack" that puts the builtin bool definition at the beginning of a
module if present. This was the easiest way to handle the implicit
dependency of the builtin stringToNat with bool in the internal-to-core
translation.
- A moderately sized test defining a simple lambda calculus involving
and an evaluator for it. This example showcases mutually recursive types
in juvix.
---------
Co-authored-by: Jonathan Cubides <jonathan.cubides@uib.no>
This PR upgrades our Haskell configurations to compile with version
9.2.7. The checklist below can serve as a guide for similar future
updates:
- [x] Update Stack resolver in `stack.yaml`
- [x] Modify `tested-with` section in `package.yaml`
- [x] Build and push the new compiler docker image, see instructions
here
[docker/README.md](https://github.com/anoma/juvix/blob/main/docker/README.md):
`ghcr.io/paulcadman/ghc-alpine:9.2.7 container`.
- [x] Update Linux Github Action workflow in
`.github/workflows/linux-static-binary.yaml` and adjust
`docker/Dockerfile-ghc-alpine-9.2.7`
- [x] Revise GHC/Stack/Cabal versions in `.devcontainer/Dockerfile`
- [x] Refresh Cabal configuration in `cabal-project`
Previously if you call Juvix on a file that doesn't exist you get the
error:
```
$ juvix compile /i/don't/exist.juvix
juvix: /i/dont: changeWorkingDirectory: does not exist (No such file or directory)
```
After this change you will see:
```
$ juvix compile /i/don't/exist.juvix
The input path "/i/dont/exist.juvix" does not exist
```
This PR fixes the behaviour of the `format` command when run on a
project that contains subprojects. Files in subprojects must not be
processed by the formatter.
The format issue was caused by a bug in the `walkDirRel` function that
is used to traverse a file system tree:
9a64184253/src/Juvix/Data/Effect/Files.hs (L36)
In this function, the passed handler can return a function that
determines if a candidate subdirectory should be traversed. The first
argument of this function indicates if the candidate subdirectory
contains a juvix.yaml file. In the formatter and the path resolver we
use this argument to exclude such subdirectories from the traversal.
Previously the first argument was calculated from the files in the
current directory instead of the candidate subdirectory - which was the
source of the bug.
The callers of walkDirRel are also fixed to match the updated behaviour.
* Closes https://github.com/anoma/juvix/issues/2077
This pr fixes the following:
This example causes the compiler to crash with "implicitness mismatch".
```
f : id Bool -> Bool;
f _ := false;
```
The reason is that `id` expects an implicit argument but finds `Bool`,
which is explicit. The arity checker was not inserting any hole because
it was ignoring the whole type. Moreover the aritychecker was never
checking `->` types as we never expected to
have to insert holes in `->` types (since the only fragment of defined
functions that we accept in types are those which do not have implicit
arguments).
We now properly arity check all types and process the function type `->`
correctly.
This change, instead of changing the `FormatOptions` data type to have
some `AppPath *`, it just adds the special case on how to handle this
specific command to figure out its input directory.
- Fixes#2058
The binary inside the Juvix release archive is now named `juvix` so this
PR updates the script that unzips and adds the juvix binary to the
devcontainer PATH to expect this.
Also see: https://github.com/anoma/juvix-docs/pull/8
# Description
This PR fixes#1943. The primary issue stemmed from an incorrect
insertion in the set designated for storing negative type parameters.
Additionally, there was a call site intended to use the variable `typ`,
but I mistakenly used `ty` (which was for something else). To prevent
such silly typos better to adopt more meaningful names.
This PR adds support for importing modules from within a Juvix project
in the Juvix REPL.
The imported module is checked (parsed, arity-checked, type-checked etc)
as normal and added to the REPL session scope. Any errors during the
checking phase is reported to the user.
### Notes:
* You must load a file before using `import`. This is because the REPL
needs to know which Juvix project is active.
* You may only import modules from within the same Juvix project.
### Examples
After launching `juvix repl`:
#### `open import`
```
Stdlib.Prelude> open import Stdlib.Data.Int.Ord
Stdlib.Prelude> 1 == 1
true
```
#### `import as`
```
Stdlib.Prelude> import Stdlib.Data.Int.Ord as Int
Stdlib.Prelude> 1 Int.== 1
true
```
#### `import`then `open`
```
Stdlib.Prelude> import Stdlib.Data.Int.Ord as Int
Stdlib.Prelude> open Int
Stdlib.Prelude> 1 == 1
true
```
#### Line-terminating semicolons are ignored:
```
Stdlib.Prelude> import Stdlib.Data.Int.Ord as Int;;;;;
Stdlib.Prelude> 1 Int.== 1
true
```
* Closes https://github.com/anoma/juvix/issues/1951
---------
Co-authored-by: Jonathan Cubides <jonathan.cubides@uib.no>
This PR updates the juvix-stdlib submodule. In particular the update
contains the new traits implemented in
https://github.com/anoma/juvix-stdlib/pull/54.
---------
Co-authored-by: Jan Mas Rovira <janmasrovira@gmail.com>
This pr fixes a bug where the repl would crash if it had the implicit
stdlib dependency and the .juvix-build/stdlib directory did not yet
exist. This bug was not exposed in the smoke tests because the
.juvix-build was never cleared.
---------
Co-authored-by: Paul Cadman <git@paulcadman.dev>
# Description
While working on highlight command, I noticed that after `format`
command changes the behaviour of the `highlight` command when both
`--stdin` option specified and FILENAME is provided is changed.
Instead on returning the result for the `stdin` input, it started to
return empty result.
This PR fixes that behaviour, it will now act exactly as before
introducing the changes that came with the `format` command fixes.
## Type of change
Please delete options that are not relevant.
- [x] Bug fix (non-breaking change which fixes an issue)
# Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works:
- [x] smoke test
# Description
This change is needed for my work on
https://github.com/anoma/vscode-juvix/issues/24 .
Now I return the information about end line and end symbol, so in
`vscode-juvix` I can handle multiline tokens properly (as VSCode can
only deal with single line tokens).
# Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works:
- [ ] Negative tests
- [ ] Positive tests
- [ ] Shell tests
# Description
No the filepath in the `juvix forma` command is n=made optional.
However, in that case, the `--stdin` command is required.
### Implementation details
~For now, as a quick solution, I have introduce the "fake" path that is
used for `fomat` command with stdin option.~
I needed to do a couple of big changes:
* `format` command FILE is now optional, howvere, I check that in case
of `Nothing` `--stdin` option should be present, otherwise it will fail
* `entryPointModulePaths` is now `[]` instead of `NonEmpty`
* `ScopeEff` now has `ScopeStdin` constructor as well, which would take
the input from stdin instead of having path passed around
* `RunPipelineNoFileEither` is added to the `App` with the bunch of
`*Stdin` functions that doesn't require filepath argument to be passed
Fixes#2008
## Type of change
- [x] New feature (non-breaking change which adds functionality)
# Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works:
- [x] smoke tests
---------
Co-authored-by: Paul Cadman <git@paulcadman.dev>
Co-authored-by: janmasrovira <janmasrovira@gmail.com>
* Closes#1965
* Implements the `unroll` pragma to control the unrolling depth on a
per-function basis.
* Implements parsing of the `inline` pragma.
---------
Co-authored-by: janmasrovira <janmasrovira@gmail.com>
- Closes#2006
During lambda lifting, we now substitute the calls to the lifted
functions before recursively applying lambda lifting. This will slightly
increase the amount of captured variables. However, I think this is the
only way since we need all identifiers to have a type when recursing.
- Closes#2016
This pr is a work in progress towards respecting empty lines with
respect to comments.
While the algorithm is supposed to work in general, I've focused on
testing it on comments between statements.
See
13442eee34/tests/positive/Format.juvix
to see some examples
If an import statement to a missing module occurs when parsing in a
project with no dependencies the error message has the following form:
```
The module Foo does not exist.
It should be in /Users/paul/heliax/juvix-2023/tests/negative/NoDependencies/Foo.juvix
or in one of the dependencies:
```
This PR changes this error message to the `or in one of the
dependencies:` line is omitted from the error message when there are no
dependencies in the project.
This commit also adds a negative parse error test for missing module.
This PR adds the `juvix clean` command to the CLI that removes the Juvix
project build directory.
It respects the `--internal-build-dir` global option:
```
$ juvix compile Foo.juvix --internal-build-dir /tmp/build
$ juvix clean --internal-build-dir /tmp/build
```
In addition this PR fixes the `juvix format` program brief description
string. This was too long for the `juvix --help` display. The longer
description is now only displayed when `juvix format --help` is run.
* Closes https://github.com/anoma/juvix/issues/2017
* Exploration of #2008
As I were trying to fix the behaviour of `format` command with the
`--stdin` global option, I noticed that actually it is already behaves
the same was as `dev scope` command (which was the desire at least at
this point).
So, no actual behaviour of the command is channged, only a few tests
added to showcase some edge cases of the command with the `--stdin`
option together.
Here are the highlights:
* The filename is **not** optional for both `dev scope` and `format`
even if with `stdin` the content of the file comes from the input.
* `format` command expects the stdin input to be a proper module
* the name of the stdin module should be aligned with the provided
filename even though its sources are not used
I think that some of the above behaviours we can consider to change. Let
me know what do you think about any of that.
Otherwise, the `dev scope` command can be replaced with `format`.
Currently the arity checker assumes that applications within a type
signature have arity unit. This is not the case where a type alias
function is used within a type signature that returns a positive arity
function type.
For example:
```
type T :=
| t : T;
funAlias : Type -> Type;
funAlias a := a -> a;
f : funAlias T;
f t := t;
```
* Closes https://github.com/anoma/juvix/issues/2020
Co-authored-by: Co-authored-by: janmasrovira <janmasrovira@gmail.com>
- Closes#1993
This pr makes it possible to use `~`, `..` and environment variables in
the `juvix.yaml` and all flags / input of the cli.
In the CLI, the shell will be responsible for replacing environment
variables with their value, so the usual syntax can be used. For the
`dependencies` field, I have implemented a parser that has some
restrictions:
1. Environment variables are given with the makefile-like syntax
`$(VAR)`
2. The three characters `$` `(` `)` are reserved for the environment
variables syntax.
They cannot be part of the path.
3. `~` is reserved for `$(HOME)`. I.e. the prepath `~~` will expand to
`$HOME$HOME`.
4. Nested environment variables are not allowed.
Thanks @paulcadman for the feedback. I think we are ready to merge this
nightmarish pr 👻
---------
Co-authored-by: Paul Cadman <git@paulcadman.dev>
This PR modifies the pretty printer for lambda clauses so that the body
will start on a new line if it is too long to fit on a single line. This
is exactly how we handle function clause bodies.
* Closes https://github.com/anoma/juvix/issues/2014
