1. A new option `show_json_schema` which, when enabled, will print the JSON schema of the command output if the target isn't an ANSI-capable terminal.
2. Some modifications to the help message and error handling for the new option `show_json_schema`.
This is now done to avoid flooding the help screen with an entire
JSON schema. Plus, it makes the schema more easily exportable as an
actual JSON schema.
Before this commit, we would require those target a specific handler,
whereas they are in fact global to the entire validator.
So now, we recover the behaviour from before where we default to the
only available validator when there's no ambiguity.
Note that this also solves the need for repeatedly applying parameters
to each handler of a parameterized validator. The command now
rightfully apply parameters to each corresponding handler.
For the program to be consistent, the 'EventListener' target that we
pass to a Project should be responsible for the output format.
Otherwise, we are contingent on developers to remember passing the
option at call-site. Plus, it overloads the project code with an extra
boolean option.
Instead, since the behaviour is solely driven by the execution
context, we can instantiate a different event target upfront, and
simply hold on to it throughout the program.
As a nice side-effect, we can gently re-organize the code to keep the
terminal printing logic and the json printing logic separate.
It has somehow always annoyed me that we have --trace_level (with 'trace' first) and --filter_traces (with traces, plural and last). Given that these two options are almost always used together, the inconsistency is frustrating.
The playground doesn't / cannot depend on aiken-project because that becomes a gigantic pain. So instead, we try to keep essential stuff inside aiken-lang when possible.
Let's consider the following case:
```
type Var =
Integer
type Vars =
List<Var>
```
This incorrectly reports an infinite cycle; due to the inability to
properly type-check `Var` which is also a dependent var of `Vars`. Yet
the real issue here being that `Integer` is an unknown type.
This commit also upgrades miette to 7.2.0, so that we can also display
a better error output when the problem is actually a cycle.
We simply provide a flag with a free-form output which acts as
the module to lookup in the 'env' folder. The strategy is to replace
the environment module name on-the-fly when a user tries to import
'env'.
If the environment isn't found, an 'UnknownModule' error is raised
(which I will slightly adjust in a following commits to something more
related to environment)
There are few important consequences to this design which may not seem
immediately obvious:
1. We parse and type-check every env modules, even if they aren't
used. This ensures that code doesn't break with a compilation error
simply because people forgot to type-check a given env.
Note that compilation could still fail because the env module
itself could provide an invalid API. So it only prevents each
modules to be independently wrong when taken in isolation.
2. Technically, this also means that one can import env modules in
other env modules by their names. I don't know if it's a good or
bad idea at this point but it doesn't really do any wrong;
dependencies and cycles are handlded all-the-same.
Using 'pallas' as a dependency brings utxo-rpc other annoying dependencies such as _tokyo_. This not only makes the overall build longer, but it also prevents it to even work when targetting wasm.
- Doesn't allow pattern-matching on G1/G2 elements and strings,
because the use cases for those is unclear and it adds complexity to
the feature.
- We still _parse_ patterns on G1/G2 elements and strings, but emit an
error in those cases.
- The syntax is the same as for bytearray literals (i.e. supports hex,
utf-8 strings or plain arrays of bytes).
KtorZ