This improves error messages for `a |> b(x)`.
We need to do a special check when looping over the args
and unifying. This information is within a function that does not belong
to pipe typer so I used a closure to forward along a way to add
metadata to the error when the first argument in the loop has a
unification error. Simply adding the metadata at the pipe typer
level is not good enough because then we may annotate regular
unification errors from the args.
The 'HEAD' call that is done to resolve package revisions from
unpinned versions is already quite cheap, but it would still be better
to avoid overloading Github with such calls; especially for users of a
language-server that would compile on-the-fly very often. Upstream
packages don't change often so there's no need to constantly check the
etag.
So we now keep a local version of etags that we fetched, as well as a
timestamp from the last time we fetched them so that we only re-fetch
them if more than an hour has elapsed. This should be fairly resilient
while still massively improving the UX for people showing up after a
day and trying to use latest 'main' features.
This means that we now effectively have two caching levels:
- In the manifest, we store previously fetched etags.
- In the filesystem, we have a cache of already downloaded zip archives.
The first cache is basically invalidated every hour, while the second
cache is only invalidated when a etag changes. For pinned versions,
nothing is invalidated as they are considered immutable.
It was not consuming the next case if there was no condition being checked in the clause.
Now it properly always consumes the next clause unless last clause.
closes#553
* rename flat to encode
* rename unflat to decode
* alias both to their old names
* both only print to stdout
use can pipe to file
* split cbor and hex flags
* hex flag works for either cbor or flat
* encode takes --to flag
[name, named-debruijn, debruijn]
* decode takes --from flag
[name, named-debruijn, debruijn]
* rename force_wrap to force
* add a bunch of builder methods to Term<Name>
* refactor one tiny location to show off builder methods
* split generate into `generate` and `generate_test`
* create wrap_as_multi_validator function
Co-authored-by: Kasey White <kwhitemsg@gmail.com>
And disable multi-patterns clauses. I was originally just controlling
whether we did disable that from the parser but then I figured we
could actually support multi-patterns clauses quite easily by simply
desugaring a multi-pattern into multiple clauses.
This is only a syntactic sugar, which means that the cost of writing
that on-chain is as expensive as writing the fully expanded form; yet
it seems like a useful shorthand; especially for short clause
expressions.
This commit however disables multi-pattern when clauses, which we do
not support in the code-generation. Instead, one pattern on tuples for
that.
This leads to more consistent formatting across entire Aiken programs.
Before that commit, only long expressions would be formatted on a
newline, causing non-consistent formatting and additional reading
barrier when looking at source code.
Programs also now take more vertical space, which is better for more
friendly diffing in version control systems (especially git).
-> The provided Plutus code called 'error'.
This scenario _could_ work if `choose_data` was lazy in its arguments.
Which is a reasonable thing to expect from `choose_data`. Since we
don't have any way to introduce on-demand lazyness in the language
(and we are not looking for ways), we need to make a special case for
`choose_data` which is a perfect (and singular) use case for it.
Editor configurations and other system-specific files aren't meant to
be committed to public repository. This belongs to a dev environment
and should be handled by developers themselves though local git
configurations.
-Builitins IR now acts like Record IR in terms of argument consumption
-UnConstrData returns as Pair(Data,Data) to conform with how pairs are treated behind the scenes.
This is not supported by the code generation, so it's a bit of a lie
to have them in the language in the first place. There's arguably not
even any use for constant records, list and tuples to begin with. So
this cleans this up everywhere for the sake of moving forward with the
alpha release.
This now reduces constants to:
- Integer
- ByteArray
- String
Anything else can be declared via a function anyway. We can revisit
this choice later.... or not.
```
Error:
× Main thread panicked.
├─▶ at crates/uplc/src/optimize.rs:16:68
╰─▶ called `Result::unwrap()` on an `Err` value: FreeUnique(Name { text: "tests_bar", unique: Unique(1) })
```
```
Error:
× Main thread panicked.
├─▶ at crates/uplc/src/optimize.rs:16:68
╰─▶ called `Result::unwrap()` on an `Err` value: FreeUnique(Name { text: "tests_bar", unique: Unique(1) })
```
**a**
```
× Main thread panicked.
├─▶ at crates/uplc/src/optimize.rs:16:68
╰─▶ called `Result::unwrap()` on an `Err` value: FreeUnique(Name { text: "__other_clauses_delayed", unique: Unique(13) })
```
**b**
```
× Main thread panicked.
├─▶ at crates/aiken-lang/src/builder.rs:771:14
╰─▶ not yet implemented: Assign
```
**c**
```
× choice_4 failed
help: ┍━ left ━━━━━━━━━━━━━┑
│ (con data #d87a80) │
┕━━━━━━━━━━━━━━━━━━━━┙
should be equal to
┍━ right ━━━━━━━━━━━━━━━━━━┑
│ (con data #d8799f182aff) │
┕━━━━━━━━━━━━━━━━━━━━━━━━━━┙
```
This however enforces that the argument unifies to a `String`. So this
is more flexible than the previous form, but does fundamentally the
same thing.
Fixes#378.
Not sure what this special case was trying to achieve, but it's not right. There's no need to handle function call with a single argument differently than the others.
microproofs