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) })
```
Tracing is now turn OFF by default when:
- building project
- building documentation
- building dependencies
It can be turned ON only when building project using `--keep-traces`.
That means it's not possible to build dependencies with traces. The
address `--rebuild` flag will also rebuild without traces.
Tracing is however turn ON by default when:
- checking the project (and running tests).
In this scenario, tracing can be disabled using `--no-traces` (if for
example, one want to analyze the execution units of specific functions
without having to manually remove traces from code).
This caused me some trouble. In my first approach, I ended up having
multiple traces because nested values would be evaluated twice; once
as condition, and once as part of the continuation.
To prevent this, we can simply evaluate the condition once, and return
plain True / False boolean as outcome. So this effectively transforms any
expression:
```
expr
```
as
```
if expr { True } else { trace("...", False) }
```
Interestingly enough, chumsky seems to fail when given a 'choice' with
more than 25 elements. That's why this commit groups together some of
the choices as another nested 'choice'.
The goal is to handle this without bothering the code generation down the line. That is, we can handle it when transforming from the untyped AST to the typed one. That's why there's no 'TraceIfFalse' constructor in the typed AST. It has disappeared during type-check.
```
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) })
```
We want the lookup to yield a result when there's only a single
validator; and no title is provided. So that users can simply do
'aiken address' in their project if it's unambiguous. The validator's
name is only required to disambiguate between multiple validators.
I also noticed that the order of arguments in with_validator was
wrong. Somehow.
**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) │
┕━━━━━━━━━━━━━━━━━━━━━━━━━━┙
```
Todo is fundamentally just a trace and an error. The only reason we kept it as a separate element in the AST is for the formatter to work out whether it should format something back to a todo or something else.
However, this introduces redundancy in the code internally and makes the AIR more complicated than it needs to be. Both todo and errors can actually be represented as trace + errors, and we only need to record their preferred shape when parsing so that we can format them back to what's expected.
We now parse errors as a combination of a trace plus and error term. This is a baby step in order to simplify the code generation down the line and the internal representation of todo / errors.
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.
KtorZ