* 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.
-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.
Kasey White