Commit Graph

2974 Commits

Author SHA1 Message Date
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
KtorZ
257bd23019 update changelog 2024-06-06 11:21:17 +02:00
KtorZ
216dab99d4 chore: Release 2024-06-06 11:19:34 +02:00
KtorZ
87f4ed359b Update changelog: set a release date. 2024-06-06 11:19:33 +02:00
Matthias Benkort
71ed844db0 Merge pull request #952 from aiken-lang/auto-merge-imports 2024-06-05 10:11:12 +02:00
KtorZ
d7ec2131ef Automatically merge import lines from same module.
I slightly altered the way we parse import definitions to ensure we
  merge imports from the same modules (that aren't aliased) together.

  This prevents an annoying warning with duplicated import lines and
  makes it just more convenient overall.

  As a trade-off, we can no longer interleave import definitions with
  other definitions. This should be a minor setback only since the
  formatter was already ensuring that all import definitions would be
  grouped at the top.

  ---

  Note that, I originally attempted to implement this in the formatter
  instead of the parser. As it felt more appropriate there. However, the
  formatter operates on (unmutable) borrowed definitions, which makes it
  annoyingly hard to perform any AST manipulations. The `Document`
  returns by the format carries a lifetime that prevents the creation of
  intermediate local values.

  So instead, slightly tweaking the parser felt like the right thing to
  do.
2024-06-04 10:48:42 +02:00
KtorZ
7f4ca60d9a refresh README. 2024-05-31 09:48:14 +02:00