Commit Graph

2980 Commits

Author SHA1 Message Date
KtorZ 976262c2e6
Allow discard in expect.
Fixes #967.
2024-07-17 18:11:09 +02:00
KtorZ 61a991cb23
Merge branch 'benchmark-knights' 2024-07-17 13:01:32 +02:00
KtorZ 46b82fac86
Split benchmarks out of acceptance tests job. 2024-07-17 13:01:17 +02:00
KtorZ e074037838
Move benchmarks one level up. 2024-07-17 13:00:57 +02:00
KtorZ 30d3898b5b
Add Rust cache to continuous integration workflow. 2024-07-17 12:56:41 +02:00
KtorZ 52974aed75
Add clausify benchmark. 2024-07-17 12:53:19 +02:00
KtorZ 20e606e645
Add benchmarks to continuous integration workflow. 2024-07-17 12:53:18 +02:00
Matthias Benkort 28d2ee7186
Delete examples/benchmarks/.github/workflows/tests.yml 2024-07-17 12:52:29 +02:00
KtorZ f14dab9547
Collect results from previous versions in a README. 2024-07-17 12:52:29 +02:00
KtorZ 5b0a1716b5
Fix mk_starts and second_last in knights benchmarks.
mk_starts was not yielding enough values. It's originally a translation of a double list comprehension in Haskell, which cannot simply be translated to a map2. The latter combine elements two by two, but the former works through all possible permutations.
2024-07-17 12:52:29 +02:00
KtorZ 65afb11546
Implement quicksort on chess board.
Note that it might be easier / cheaper to serialize and compare bytes?
2024-07-17 12:52:29 +02:00
KtorZ f2ff9a2ee3
Review knights benchmark and update dependencies. 2024-07-17 12:52:29 +02:00
microproofs 1d16cbf386
more benchmark work 2024-07-17 12:52:29 +02:00
microproofs c62821e02a
continue porting over knights example 2024-07-17 12:52:29 +02:00
microproofs 8f825f68b1
commit new example for benchmarking 2024-07-17 12:52:28 +02:00
KtorZ fe7d744946
Split continuous workflow in three jobs.
Doing all steps sequentially is starting to get long. Several of those checks are unrelated and can be done in parallel.
2024-07-16 17:41:14 +02:00
KtorZ 0145237bbe
Version wix boilerplate. 2024-07-16 17:33:49 +02:00
KtorZ e9f7e96970
Update cargo-dist setup and generated artifacts. 2024-07-16 17:30:11 +02:00
Matthias Benkort c52ba9c873
Merge pull request #971 from rober-m/main
Solved: Nix expression broken in Darwin
2024-07-02 15:46:23 +02:00
Robertino fef3626498
Fix: Nix expression doesn't work in Darwin 2024-07-02 11:51:46 +01:00
KtorZ 5da7db355f
Use ubuntu-22.04 for linux releases, and add musl target.
This should fix the openssl linking issue, as well as provide an alternative linux build that should be fully static.
2024-07-01 17:34:13 +02:00
Matthias Benkort 8b86ee8219
Merge pull request #962 from waalge/w/bump-nix
bump nix: use rustc 1.79, add analyzer to devshell
2024-07-01 15:43:09 +02:00
rvcas 5bdea11cc1 fix: add a new assignment kind instead of using a boolean 2024-06-25 18:50:00 -04:00
microproofs f1cfc84e67 Fix tree traversal node selection for a few of the enum variants 2024-06-25 18:50:00 -04:00
microproofs 9907dd6c64 Fix unit tests 2024-06-25 18:50:00 -04:00
microproofs 4bd9125b86 Fix delay of arguments to be exactly the same as codegen tests 2024-06-25 18:50:00 -04:00
microproofs f695276bf7 Fix codegen tree traversal to be updated for the otherwise field and future proof the traversal function 2024-06-25 18:50:00 -04:00
microproofs b5ac5bc949 Add current fixed tests and start working on codegen fix 2024-06-25 18:50:00 -04:00
microproofs f0f1296906 Fix more tests 2024-06-25 18:50:00 -04:00
microproofs cc9df04093 Fix missing delay in list_access_to_uplc. Also fix one of the unit tests. 2024-06-25 18:50:00 -04:00
microproofs 41b941e0e3 Fix castfromData in record access cases 2024-06-25 18:50:00 -04:00
KtorZ 00d1927dad Add few more test cases for the parser and type-checker. 2024-06-25 18:50:00 -04:00
rvcas aeb079334e chore: this test doesn't make sense anymore 2024-06-25 18:50:00 -04:00
rvcas 8f343abaa1 chore: add new snapshots 2024-06-25 18:50:00 -04:00
microproofs e09f6bbc87 delay otherwise branch to prevent premature errors 2024-06-25 18:50:00 -04:00
microproofs df939e20ce missed a Air Op Code and updated how we pass in otherwise for assignment 2024-06-25 18:50:00 -04:00
rvcas 7da35d5d73 chore: add acceptance tests for if/is 2024-06-25 18:50:00 -04:00
rvcas 579abb7d3d fix: no need to check exhaustiveness during if/is 2024-06-25 18:50:00 -04:00
rvcas 5024bd3f9c feat: code gen support for if/is
Co-authored-by: Kasey White <kwhitemsg@gmail.com>
2024-06-25 18:50:00 -04:00
rvcas 1b8805825b feat: impl if/is
This commit introduces a new feature into
the parser, typechecker, and formatter.
The work for code gen will be in the next commit.

I was able to leverage some existing infrastructure
by making using of `AssignmentPattern`. A new field
`is` was introduced into `IfBranch`. This field holds
a generic `Option<Is>` meaning a new generic has to be
introduced into `IfBranch`. When used in `UntypedExpr`,
`IfBranch` must use `AssignmentPattern`. When used in
`TypedExpr`, `IfBranch` must use `TypedPattern`.

The parser was updated such that we can support this
kind of psuedo grammar:

`if <expr:condition> [is [<pattern>: ]<annotation>]`

This can be read as, when parsing an `if` expression,
always expect an expression after the keyword `if`. And then
optionally there may be this `is` stuff, and within that you
may optionally expect a pattern followed by a colon. We will
always expect an annotation.

This first expression is still saved as the field
`condition` in `IfBranch`. If `pattern` is not there
AND `expr:condition` is `UntypedExpr::Var` we can set
the pattern to be `Pattern::Var` with the same name. From
there shadowing should allow this syntax sugar to feel
kinda magical within the `IfBranch` block that follow.

The typechecker doesn't need to be aware of the sugar
described above. The typechecker looks at `branch.is`
and if it's `Some(is)` then it'll use `infer_assignment`
for some help. Because of the way that `is` can inject
variables into the scope of the branch's block and since
it's basically just like how `expect` works minus the error
we get to re-use that helper method.

It's important to note that in the typechecker, if `is`
is `Some(_)` then we do not enforce that `condition` is
of type `Bool`. This is because the bool itself will be
whether or not the `is` itself holds true given a PlutusData
payload.

When `is` is None, we do exactly what was being done
previously so that plain `if` expressions remain unaffected
with no semantic changes.

The formatter had to be made aware of the new changes with
some simple changes that need no further explanation.
2024-06-25 18:50:00 -04:00
rvcas b2c42febaf chore: move if_branch to helper parser 2024-06-25 18:50:00 -04:00
Dima S d99c014bf7 chore: correct the usage of a legacy numeric constant 2024-06-25 17:49:36 -04:00
Dima S 1e195156d7 chore(ci): Bump actions/checkout from 3 to 4 2024-06-25 17:49:36 -04:00
waalge 372b186103 nix use rustc 1.79. Add analyzer to devshell 2024-06-19 15:18:18 +00:00
rvcas de870e2529
feat: warning on compiler version mismatch 2024-06-13 20:26:44 -04:00
KtorZ 0ebffa2b9e
Fix few error messages. 2024-06-13 14:54:47 +02:00
Matthias Benkort 3ddd088780
Merge pull request #955 from aiken-lang/allow-complete-patterns-in-args
Allow complete patterns in args
2024-06-07 16:10:06 +02:00
KtorZ 858dfccc82
Authorize complete patterns as function args.
This is mainly a syntactic trick/sugar, but it's been pretty annoying
  to me for a while that we can't simply pattern-match/destructure
  single-variant constructors directly from the args list. A classic
  example is when writing property tests:

  ```ak
  test foo(params via both(bytearray(), int())) {
    let (bytes, ix) = params
    ...
  }
  ```

  Now can be replaced simply with:

  ```
  test foo((bytes, ix) via both(bytearray(), int())) {
    ...
  }
  ```

  If feels natural, especially coming from the JavaScript, Haskell or
  Rust worlds and is mostly convenient. Behind the scene, the compiler
  does nothing more than re-writing the AST as the first form, with
  pre-generated arg names. Then, we fully rely on the existing
  type-checking capabilities and thus, works in a seamless way as if we
  were just pattern matching inline.
2024-06-07 15:42:25 +02:00
KtorZ b6da42baf2
Bump 'is_validator_param' up from 'ArgName' to '...Arg'
There's no reasons for this to be a property of only ArgName::Named to begin with. And now, with the extra indirection introduced for arg_name, it may leads to subtle issues when patterns args are used in validators.
2024-06-07 11:32:05 +02:00
KtorZ 4d42c6cb19
Introduce 'ArgBy' to allow defining function arg not only by name. 2024-06-07 11:17:16 +02:00