1
1
mirror of https://github.com/anoma/juvix.git synced 2024-12-25 16:45:20 +03:00
Commit Graph

1608 Commits

Author SHA1 Message Date
Paul Cadman
a63314d475
Update cabal.project.freeze for GHC 9.10.1 update (#3035)
This PR updates the cabal freeze file to reflect the changes to
dependencies after the GHC 9.10.1 stack.yaml update.

@janmasrovira can you check this? The last time I think you updated this
and the freeze file was much smaller for you.

I downloaded the stack2cabal binary from
https://github.com/hasufell/stack2cabal/releases/latest and ran
`stack2cabal` in the root of our repo.

* Fixes https://github.com/anoma/juvix/issues/3036
2024-09-13 19:50:06 +01:00
Łukasz Czajka
b609e1f6a5
Don't fold lets if the let-bound variable occurs under a lambda-abstraction (#3029)
* Closes #3002
2024-09-13 19:29:39 +02:00
Paul Cadman
ef0bc6efb8
Update linux static binary workflow for GHC 9.10.1 (#3034)
This PR updates the GHC version and the stack version in the linux
static binary GitHub workflow. This is used to make Juvix linux binary
releases.

NB: The linux binary releases of stack no longer have the `-static`
suffix in the tar filename.
2024-09-13 17:52:51 +02:00
Łukasz Czajka
87adaf4512
Update to GHC 9.10.1 (#2991)
Since GHC 9.8.2 has a bug which blocks our development (see
https://github.com/anoma/juvix/pull/2977#issuecomment-2325866056), I
made a PR to update to GHC 9.10.1. Because stackage doesn't yet support
GHC 9.10.1, I had to add some explicit dependencies and use
`allow-newer-deps` in `stack.yaml`.

I think we should merge this not to get blocked by the bug, and later
clean up `stack.yaml` when GHC 9.10.1 becomes supported on stackage.

---------

Co-authored-by: Paul Cadman <git@paulcadman.dev>
2024-09-13 15:26:43 +02:00
Jan Mas Rovira
9d9591617d
Remove old named application syntax (#3026)
- Closes #2948
2024-09-12 19:27:29 +02:00
Łukasz Czajka
56e2db7336
Fix JuvixTree parsing and pretty printing (#3024)
Recent changes to the compiler left JuvixTree parsing and pretty
printing not in sync with each other.
2024-09-12 14:37:51 +02:00
Łukasz Czajka
c1774ffb76
Fix RISC0 in the CI (#3025) 2024-09-12 12:29:23 +02:00
Łukasz Czajka
26ea94b977
The assert builtin (#3014)
* Requires #3015
2024-09-12 09:29:57 +02:00
Jan Mas Rovira
8e204634b8
Fix the location in the parser for .juvix.md (#3020)
This pr makes it possible to properly hihglight .juvix.md files
2024-09-11 14:07:16 +02:00
Jan Mas Rovira
799d85034f
Store the DocTable in the .jvo file (#3021)
This allows the ide to display documentation for identifiers defined in
other modules.
2024-09-11 13:14:34 +02:00
Łukasz Czajka
5d3550b760
Fix bug in symbol dependency graph generation in Core (#3018)
The graph was missing some edges, which led to too many symbols being
filtered out by the `filter-unreachable` transformation.
2024-09-11 09:30:40 +02:00
Łukasz Czajka
5d0aa6ea54
Fix RISC0 compilation on the CI (#3015) 2024-09-10 17:17:00 +02:00
Jan Mas Rovira
d8919087dd
Fix location of scoped modulePathName (#3011)
Closes #2737.

This issues caused the formatter to sometimes insert unwanted line
breaks.
2024-09-09 15:50:29 +02:00
Łukasz Czajka
7167cb319a
Lift non-immediate expressions out of case values for the Nockma backend (#3010)
Implements a transformation `compute-case-anf` which lifts out
non-immediate values matched on in case expressions by introducing
let-bindings for them. In essence, this is a partial ANF transformation
for case expressions only.

For example, transforms
```
case f x of { c y := y + x; d y := y }
```
to
```
let z := f x in case z of { c y := y + x; d y := y }
```
This transformation is needed to avoid duplication of values matched on
in case-expressions in the Nockma backend.
2024-09-09 14:56:36 +02:00
Jan Mas Rovira
f47b9b0034
Do not duplicate nockma stdlib in the nockma backend (#3005) 2024-09-09 14:02:47 +02:00
Jan Mas Rovira
372375ef4d
Only output .debug.nockma file with the --debug flag (#3006) 2024-09-09 13:16:32 +02:00
Łukasz Czajka
ab2d31a313
Compilation of side conditions in pattern matches (#2984)
* Closes #2804 
* Requires #3003
* Front-end syntax for side conditions was implemented in #2852. This PR
implements compilation of side conditions.
* Adds side-conditions to `Match` nodes in Core. Updates Core parsing,
printing and the evaluator.
* Only side-conditions without an `else` branch are allowed in Core. If
there is an `else` branch, the side conditions are translated in
`fromInternal` into nested ifs. Because with `else` the conditions are
exhaustive, there are no implications for pattern exhaustiveness
checking.
* Adjusts the "wildcard row" case in the pattern matching compilation
algorithm to take into account the side conditions.
2024-09-09 12:25:15 +02:00
Jan Mas Rovira
453afffd15
Do not inline the functions library everywhere in the Nockma backend (#3004) 2024-09-08 22:39:55 +02:00
Łukasz Czajka
5675b4f480
Remove legacy naive match-to-case compiler (#3003)
Removes the naive match-to-case transformation.
2024-09-08 11:59:45 +02:00
Jan Mas Rovira
4ae4e4e4d9
Fix a bug that prevented use of name signature defined after the point (#3001)
- Fixes #2999
2024-09-06 14:32:03 +02:00
Jan Mas Rovira
e45503a63e
Fix typechecking of default arguments in signatures with trait arguments (#2998)
- Fixes #2994
2024-09-05 19:43:04 +02:00
Łukasz Czajka
d7c69db126
Fix locations in Internal hole substitution (only for the case of substituting identifiers) (#2995)
Type checking messes up the locations by substituting the holes
(instance holes and ordinary holes) without adjusting the location of
the expression substituted into the hole. Instead, the location of the
expression substituted into the hole is preserved. This messes up
locations in type-checked Internal, because the substituted expressions
can come from anywhere. Later on, the error locations are wrong in Core,
and get wrongly displayed e.g. for pattern matching coverage errors.

This PR implements a partial solution for the (most common) case when
the substituted expression is an identifier. In the future, we should
have a general solution to preserve the hole locations.
2024-09-05 10:57:30 +02:00
Paul Cadman
e4559bbc87
Release 0.6.6 (#2993)
This PR updates:

- [x] Package version
- [x] Smoke test
- [x] Changelog
2024-09-03 18:10:01 +01:00
Łukasz Czajka
b9d864123a
Isabelle/HOL translation: comments (#2974)
* Closes #2962 
* Depends on #2963 
* In Isabelle/HOL comments cannot appear in internal syntax. All
comments inside a Juvix definition are moved outside: to before the
definition or before the earliest function clause.

---------

Co-authored-by: Jan Mas Rovira <janmasrovira@gmail.com>
2024-09-02 15:56:58 +02:00
Jan Mas Rovira
9d2a2b5638
Add IsInstanceCoercion to Internal (#2981)
We now use a sum type:
```
data IsInstanceCoercion
  = IsInstanceCoercionInstance
  | IsInstanceCoercionCoercion
```
instead of two mutually exclusive Bools.

Moreover, we properly print the keyword in the internal prettyprinter.
2024-09-02 13:46:53 +02:00
Paul Cadman
87c5f0af44
Improve performance of anomaEncode / anomaDecode in the Core evaluator (#2975)
This PR:

* Adds a new implementation of {decode, encode}ByteString functions,
used by anomaEncode and anomaDecode in the Core evaluator
* Adds property tests for roundtripping and benchmarks for the new
functions.

The old implementation used
[bitvec](https://hackage.haskell.org/package/bitvec) to manipulate the
ByteString. This was far too slow. The new implementation uses bit
operations directly on the input integer and ByteArray.

It's now possible to run
[anoma-app-patterns:`Tests/Swap.juvix`](https://github.com/anoma/anoma-app-patterns/blob/feature/tests/Tests/Swap.juvix)
to completion.

For encoding, if the size of the output integer exceeds 64 bits (and
therefore a BigInt must be used) then the new implementation has
quadratic time complexity in the number of input bytes if an
implementation of `ByteString -> Integer` is used as follows:

```
byteStringToIntegerLE :: ByteString -> Integer
byteStringToIntegerLE = BS.foldr (\b acc -> acc `shiftL` 8 .|. fromIntegral b) 0
```

```
byteStringToInteger' :: ByteString -> Integer
byteStringToInteger' = BS.foldl' (\acc b -> acc `shiftL` 8 .|. fromIntegral b) 0

```

I think this is because `shiftL` is expensive for large Integers. To
mitigate this I'm splitting the input ByteString into 1024 byte chunks
and processing each separately. Using this we get 100x speed up at
~0.25Mb input over the non-chunked approach and linear time-complexity
thereafter.

## Benchmarks

The benchmarks for encoding and decoding 250000 bytes:

```
 ByteString Encoding to/from integer
      encode bytes to integer:   OK
        59.1 ms ± 5.3 ms
      decode bytes from integer: OK
        338  ms ±  16 ms
```

The previous implementation would never complete for this input.

Benchmarks for encoding and decoding 2 * 250000 bytes:

```
    ByteString Encoding to/from integer
      encode bytes to integer:   OK
        121  ms ± 8.3 ms
      decode bytes from integer: OK
        651  ms ±  27 ms
```

Benchmarks for encoding and decoding 4 * 250000 bytes:

```
    ByteString Encoding to/from integer
      encode bytes to integer:   OK
        249  ms ±  17 ms
      decode bytes from integer: OK
        1.317 s ±  16 ms
```

---------

Co-authored-by: Lukasz Czajka <lukasz@heliax.dev>
2024-08-30 18:20:18 +01:00
Jan Mas Rovira
7119d3929b
Add PartialDo effect (#2978)
This effect is a different name for [Effectful's
`Fail`](https://hackage.haskell.org/package/effectful-core-2.3.1.0/docs/Effectful-Fail.html).
It gives an instance of
[`MonadFail`](https://hackage.haskell.org/package/base-4.18.1.0/docs/Control-Monad-Fail.html#t:MonadFail)
to `Sem`
2024-08-30 16:27:08 +02:00
Paul Cadman
3d21ab4325
Monad and Applicative traits in juvix stdlib (#2979)
This PR updates the stdlib submodule to juvix-stdlib main branch.

It contains Monad and Applicative traits.
2024-08-30 15:07:29 +02:00
Jan Mas Rovira
eb00fa48ba
Improve compilation progress log (#2969)
- Closes #2797 

Changes:

1. The global flag `--dev-show-thread-ids` is now properly being passed.
Before it was ignored.
3. The progress log has been refactored out of the `ParallelTemplate`
into the `Pipeline.Driver`. With the extra information available, I've
improved how we display the progress log:
1. We show `Compiling`, `Recompiling`, `Loading` to tell if the module
is compiled for the first time (the jvo is missing), or it needs to be
recompiled (with the reason displayed in parentheses), or is loaded from
a jvo file. In the latter case, the message is only showed with
`--log-level verbose|debug`.
2. The modules in other packages are displayed as dependencies with
their own progress counter.
2. When using `-N 1` and compiling a whole project we also get progress
log.

Example screencast:


https://github.com/user-attachments/assets/7cc43cd4-9b23-4ad5-a863-832abacc1b6c
2024-08-30 00:10:13 +02:00
Łukasz Czajka
a4f3704f4e
Isabelle/HOL translation: records and named patterns (#2963)
* Closes #2894 
* Closes #2895
* The translation of pattern matching on records is a bit tricky because
one cannot pattern match on records in Isabelle, except in top patterns
of function clauses. We thus need to translate into nested pattern
matching and record projections. Named patterns can be translated with a
similar technique and are also handled in this PR.

Checklist
---------
- [x] record creation
- [x] record projections
- [x] record update
- [x] top-level record patterns
- [x] nested record patterns
- [x] named patterns
- [x] remove redundant pattern matching clauses
- [x] remove redundant single-branch pattern matches
2024-08-29 16:15:58 +02:00
Jan Mas Rovira
e0bbac2d11
Improve output of juvix dev import-tree print (#2976)
Example:

Old:
```
Import Tree:
============

* Package at /home/jan/.config/juvix/0.6.5/package-base/
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/Bool.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/List.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/Maybe.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/Nat.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/String.juvix
Juvix/Builtin/V1.juvix imports Juvix/Builtin/V1/Trait/Natural.juvix
Juvix/Builtin/V1/List.juvix imports Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1/Nat.juvix imports Juvix/Builtin/V1/Nat/Base.juvix
Juvix/Builtin/V1/Nat.juvix imports Juvix/Builtin/V1/Trait/FromNatural.juvix
Juvix/Builtin/V1/Nat.juvix imports Juvix/Builtin/V1/Trait/Natural.juvix
Juvix/Builtin/V1/Nat/Base.juvix imports Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1/String.juvix imports Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1/Trait/FromNatural.juvix imports Juvix/Builtin/V1/Nat/Base.juvix
Juvix/Builtin/V1/Trait/Natural.juvix imports Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1/Trait/Natural.juvix imports Juvix/Builtin/V1/Nat/Base.juvix
Juvix/Builtin/V1/Trait/Natural.juvix imports Juvix/Builtin/V1/Trait/FromNatural.juvix
```

New:
```
Import Tree:
============

* Package at /home/jan/.config/juvix/0.6.5/package-base/
Nodes (10)
Juvix/Builtin/V1/Nat.juvix
Juvix/Builtin/V1/Nat/Base.juvix
Juvix/Builtin/V1/Fixity.juvix
Juvix/Builtin/V1/Trait/Natural.juvix
Juvix/Builtin/V1/Bool.juvix
Juvix/Builtin/V1.juvix
Juvix/Builtin/V1/List.juvix
Juvix/Builtin/V1/String.juvix
Juvix/Builtin/V1/Trait/FromNatural.juvix
Juvix/Builtin/V1/Maybe.juvix

Edges (17)
Juvix/Builtin/V1.juvix imports (7):
  • Juvix/Builtin/V1/Bool.juvix
  • Juvix/Builtin/V1/Fixity.juvix
  • Juvix/Builtin/V1/List.juvix
  • Juvix/Builtin/V1/Maybe.juvix
  • Juvix/Builtin/V1/Nat.juvix
  • Juvix/Builtin/V1/String.juvix
  • Juvix/Builtin/V1/Trait/Natural.juvix

Juvix/Builtin/V1/Bool.juvix imports (0):

Juvix/Builtin/V1/Fixity.juvix imports (0):

Juvix/Builtin/V1/List.juvix imports (1):
  • Juvix/Builtin/V1/Fixity.juvix

Juvix/Builtin/V1/Maybe.juvix imports (0):

Juvix/Builtin/V1/Nat.juvix imports (3):
  • Juvix/Builtin/V1/Nat/Base.juvix
  • Juvix/Builtin/V1/Trait/FromNatural.juvix
  • Juvix/Builtin/V1/Trait/Natural.juvix

Juvix/Builtin/V1/Nat/Base.juvix imports (1):
  • Juvix/Builtin/V1/Fixity.juvix

Juvix/Builtin/V1/String.juvix imports (1):
  • Juvix/Builtin/V1/Fixity.juvix

Juvix/Builtin/V1/Trait/FromNatural.juvix imports (1):
  • Juvix/Builtin/V1/Nat/Base.juvix

Juvix/Builtin/V1/Trait/Natural.juvix imports (3):
  • Juvix/Builtin/V1/Fixity.juvix
  • Juvix/Builtin/V1/Nat/Base.juvix
  • Juvix/Builtin/V1/Trait/FromNatural.juvix
```
2024-08-28 12:26:45 +02:00
Łukasz Czajka
7c8ac153e6
Don't fold lets with fail, trace or >-> in the body (#2973)
This is to avoid optimizing e.g.
```
let x := A in
trace "after A" >-> x
```
into 
```
trace "after A" >-> A
```
which is annoying when debugging.
2024-08-27 15:52:08 +02:00
Łukasz Czajka
eb5b2e4595
Fix JuvixTree type unification (#2972)
* Closes #2954 
* The problem was that the type validation algorithm was too strict for
higher-order functions with a dynamic (unknown) target.
2024-08-27 10:31:14 +02:00
Łukasz Czajka
9c980d152a
Translate Judoc comments to Isabelle/HOL (#2958)
* Closes #2891
2024-08-23 20:43:57 +02:00
Jan Mas Rovira
2b4520c855
Fix bug where highlighting is not kept when the file has a type error and imports some other file (#2959)
Example file:
```
module error;

import empty; -- error only happens if we have at least one import

type T := t;

x : T := t t; -- type error
```
If one loads this file into emacs (or vscode) they'll get a type error
as expected, but name colors and go-to information is lost, which is
annoying. This pr fixes this.
I'm not sure why, but this bug only occurs when there is at least one
import.
2024-08-21 13:42:33 +02:00
Jan Mas Rovira
eb0922a244
Add do notation (#2937)
- Closes #2355
- Depends on #2943 

Example:
```
minusOne : Nat -> Maybe Nat
  | zero := nothing
  | (suc n) := just n;


minusThree (n : Nat) : Maybe Nat :=
  do {
    x1 <- minusOne n;
    x2 <- minusOne x1;
    let
      x2' : Nat := x2;
    in
    x3 <- minusOne x2';
    pure x3;
  };
```
2024-08-21 12:01:44 +02:00
Jan Mas Rovira
41450a88ff
Register builtins during scoping and report proper errors instead of crashing (#2943)
This pr has two relevant changes:
## Errors instead of crases
When registering a builtin, we perform some sanity checks. When
unsuccessful, the compiler crashes. This seldom happens because builtins
are defined in libraries that we write ourselves. However, any compiler
crash is a bug, so this pr refactors these crashes into proper errors.

## Registering builtins during scoping
Before this pr, builtins are registered and sanity checked during the
translation from Concrete to Internal. This imposes that the order in
which we translate stuff is relevant, as we must register a builtin
before we use it. For the most part this is fine when the dependency is
explicit in the code, but sometimes there are explicit dependencies.
E.g. do notation and the builtin `monad-bind`. In order to avoid adding
special rules, it is easier to just register builtins during scoping, so
I've refactored the code to do this.

I've also removed the `Builtins` effect and moved its methods to the
`InfoTableBuilder` since the builtins table is now part of the Scoped
InfoTable. Consequently, I've removed the the field `_artifactBuiltins`.

## Future work
- Fix #2952. I didn't find a good way to fix this problem in this pr, so
it is left for a separate pr.

---------

Co-authored-by: Paul Cadman <git@paulcadman.dev>
2024-08-20 13:23:28 +01:00
Łukasz Czajka
7df1e00235
Isabelle/HOL translation: add 'O' and 'OO' to reversed names (#2961)
As requested by Jonathan, adds 'O' and 'OO' to the list reserved
Isabelle/HOL names.
2024-08-19 18:39:08 +02:00
Łukasz Czajka
4fa5d3ca1b
Isabelle/HOL translation: the isabelle-ignore pragma (#2955)
* Closes #2940
2024-08-19 12:22:10 +02:00
Paul Cadman
8d03ac2b6c
Add anoma-bytearray-{to, from}-anoma-contents builtins (#2960)
The `anoma-bytearray-{to, from}-anoma-contents` are intended to be used
to convert to/from atoms representing `ByteArrays`. These builtins are
required temporarily until Anoma Node makes ByteArray representation
uniform across all of its APIs.

We represent ByteArrays in nock as a cell:

```
[size contents]
```

Where `size` is the size of the ByteArray and `contents` is an Atom
representing the bytes in LSB ordering.

The `size` is required in general because the encoding of ByteArrays to
Atoms is ambiguous. For example the ByteArrays [0x01; 0x00] and [0x01]
are represented by `1`.

Some Anoma ByteArrays like keys and signatures are represented using on
the `contents` atom because the size is constant.

Users of Anoma APIs have to strip / add size information from ByteArrays
depending on where the data is used. The new builtins provide this
facility.

These builtins are temporary because it's been agreed with Anoma
engineering team to change the Anoma APIs to make the ByteArray
representation uniform, i.e always represent ByteArrays using `[size
content]`. When this is implemented in Anoma Node we can remove these
builtins.

```
builtin anoma-bytearray-to-anoma-contents
axiom toAnomaContents : ByteArray -> Nat;

builtin anoma-bytearray-from-anoma-contents
axiom fromAnomaContents :
  -- | The size of the ByteArray
  Nat
  -- | The contents of the ByteArray
  -> Nat
  -- | The resulting ByteArray
  -> ByteArray;
```
2024-08-19 11:19:26 +02:00
Paul Cadman
4fe60ea85d
Release 0.6.5 (#2956)
This PR updates:

- [x] Package version
- [x] Smoke test
- [x] Changelog

We can't merge this until the stdlib submodule pointer is fixed-up to
point to stdlib main.
2024-08-14 17:48:36 +01:00
Paul Cadman
7258e66818
Update stdlib submodule to point to stdlib main (#2957)
This PR updates the stdlib submodule to point to juvix stdlib main.
2024-08-14 16:58:08 +01:00
Jan Mas Rovira
b78279c3e0
Fix inference of let and letrec in core (#2953)
* Closes #2949

---------

Co-authored-by: Paul Cadman <git@paulcadman.dev>
2024-08-14 15:15:49 +01:00
Łukasz Czajka
d60bcccffb
Isabelle/HOL name quoting (#2951)
* Closes #2941 
* Depends on #2950
2024-08-14 15:24:42 +02:00
Łukasz Czajka
fcd52a443f
Improve specialization optimization (#2944)
* Specialization has become less effective after recent changes to the
codebase. This PR fixes issues with specialization.
* Closes #2939 
* Closes #2945 

Checklist
---------
- [X] Preserve pragmas for letrec and lambda in Stored Core
- [x] Remove the assumption that all type variables are at the front
(closes #2945)
- [x] Allow specialization when the argument is a constructor
application
- [x] Make renaming adjust pragmas
- [x] Allow pragmas for fields in record definitions (closes #2939)
- [x] Update standard library pragmas
- [x] Fix JuvixTree printing
2024-08-14 10:04:30 +02:00
Łukasz Czajka
52e4e78dc8
Remove unicode from Isabelle/HOL output (#2950)
* Closes #2942
2024-08-13 18:50:25 +02:00
Paul Cadman
d759d27da7
Use ByteArray for Anoma cryptographic builtins (#2947)
This PR adds support for ByteArray in the Anoma cryptographic functions.

```
builtin anoma-sign
axiom anomaSign : {A : Type} -> A -> ByteArray -> ByteArray;

builtin anoma-verify-with-message
axiom anomaVerifyWithMessage : {A : Type} -> ByteArray -> ByteArray -> Maybe A;

builtin anoma-sign-detached
axiom anomaSignDetached : {A : Type} -> A -> ByteArray -> ByteArray;

builtin anoma-verify-detached
axiom anomaVerifyDetached : {A : Type} -> ByteArray -> A -> ByteArray -> Bool;
```

The Anoma / Hoon Stdlib function `length` needs to be exposed as a
StdlibFunction because a ByteArray stores its length and the value
returned by `anomaSign` is not a fixed length.
2024-08-13 13:17:57 +01:00
Paul Cadman
ce5c2c5c55
Add builtin ByteArray type (#2933)
This PR adds support for a builtin `ByteArray` type and associated
functions for constructing a `ByteArray` from a list of bytes and a
function to query the size of the `ByteArray`. It is only available in
the Anoma backend.

In Core / Tree, ByteArray constant is stored using a Haskell ByteString.

In Anoma the ByteArray is stored as a cell where the head is the length
of the ByteArray and the tail is an integer is an integer formed by
concatenating the bytes in the array using little-endian byte ordering.

The Nock for constructing a `ByteArray` uses the `length`, `add`,
`folder` and `lsh` functions from the Anoma hoon stdlib. See the [code
comment](fa068a30e7/src/Juvix/Compiler/Nockma/StdlibFunction.hs (L37))
for more details.

Example:

```
module test082;

import Stdlib.Prelude open;
import Stdlib.Debug.Trace open;

builtin bytearray
axiom ByteArray : Type;

builtin bytearray-from-list-byte
axiom mkByteArray : List Byte -> ByteArray;

builtin bytearray-size
axiom size : ByteArray -> Nat;

bs0 : ByteArray := mkByteArray [];

bs1 : ByteArray := mkByteArray [0x0; 0x0; 0x0];

bs2 : ByteArray := mkByteArray [0x1; 0x0; 0x0; 0x0];

bs3 : ByteArray := mkByteArray [0x2; 0x1];

bs4 : ByteArray := mkByteArray [0x100];

main : ByteArray :=
  trace (size bs0)
   >-> trace bs0
   >-> trace (size bs1)
    >-> trace bs1
    >-> trace (size bs2)
    >-> trace bs2
    >-> trace (size bs3)
    >-> trace bs3
    >-> trace (size bs4)
    >-> bs4;
```

Output using `tests/Anoma/Compilation/positive/test082.juvix`

```
$ juvix compile anoma -g test082.juvix
$ juvix dev nockma run test082.pretty.nockma
0
[0 0]
3
[3 0]
4
[4 1]
2
[2 258]
1
[1 0]
```
2024-08-13 11:13:27 +01:00
Jan Mas Rovira
2b5ece7b28
Add --statements flag to juvix dev latex export (#2946)
This pr adds the `--statements` flag to `juvix dev latex export`. It can
be used like this:
```
juvix dev latex export --statements "List; elem; find" List.juvix
```
All statements are selectable by their 'label'. The label of a statement
is defined as:
1. The function/type/operator/alias/axiom/local_module/fixity/iterator
name being defined.
2. The module name being imported.

## Limitations:
1. Only top statements are allowed. I.e. statements inside local modules
cannot be selected.
1. Open statements are not selectable. Giving `--statements "My.Module"`
will refer to the import statement `import My.Module`.
4. Single constructors are not selectable. Only the whole type
definition.
5. No comments will be printed.
2024-08-12 14:16:39 +02:00
Łukasz Czajka
206bed5ed3
Add more comments in the source code (#2938)
* Adds more comments describing some Core transformations 
* Fixes minor Core printing issues
2024-08-07 16:13:11 +02:00