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.
List Clauses patterns handle var cases
Fixed Tuple Clauses issue with last clause not being a tuple
Redid how zero arg functions and dependencies are handled. Tough one lol
And also return a structured output as JSON, so it's more easily used
by other tools.
```
Parsing script context
Simulating 78ec148ea647cf9969446891af31939c5d57b275a2455706782c6183ef0b62f1
Redeemer Spend → 0
{"mem":151993,"cpu":58180696}
```
The current implementation assumed that ALL withdrawals present in a
transaction had to be locked by a script and failed otherwise. But a
transaction can actually be composed of both. So instead of failing,
we should rather just ignore withdrawals that can't be referenced by
redeemers.
There's arguably no use case ever for that in the context of on-chain
Plutus. Strings are really just meant to be used for tracing. They
aren't meant to be manipulated as heavily as in classic programming
languages.
Before that commit, the type-checker would allow unsafe list patterns
such as:
```
let [x] = xs
when xs is {
[x] -> ...
[x, ..] -> ...
}
```
This is quite unsafe and can lead to confusing situations. Now at
least the compiler warns about this. It isn't perfect though,
especially in the presence of clause guards. But that's a start.
Whoopsie... || and && were treated with the same precedence, causing very surprising behavior down the line.
I noticed this because of the auto-formatter adding parenthesis where it really shouldn't. The problem came actually from the parser and how it constructed the AST.
KtorZ