- Ensure consistency between overall summary and individual summaries.
- Remove 'max_*' properties, since they are only padding numbers used
for formatting the terminal output.
- Rename a few fields to be closer to the existing naming (name ->
title, memory -> mem, etc..)
- Remove duplicated outputs
- Re-order fields such that summaries come first
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.
Constants are like tiny programs, so they are bound by the same rules
as validators and other programs. In fact, functions are slightly more
flexible in that they allow generic constant expressions like
`List<a>`.
Yet, there is no way to contain such generic structure that contain
inhabitants in a way that satisfies the type-checker. In the example
of `List<a>`, the only inhabitant of that type that we can construct
is the empty list. Anything else would require holding onto some
generic value.
In addition, we can't force literal values into generic annotation, as
something like:
```
const foo: List<a> = [1, 2, 3]
```
wouldn't type-check either since the right-side would unify to
`List<Int>`. And again, the only right-hand side that can type-check
is the empty list without any inhabitant.
The added restriction on generic function is necessary because while
we allow constants to return lambda, we cannot (easily) generate UPLC
that is generic in its argument. By the time we generate UPLC, the
underlying types have to be known.
Without that, the language server might trigger awkward warnings about
unused imports due to trace stripping. So it's better to compile/check
projects in the language server in the most expanded form.
This is not a "proper" fix as it simply get rid of the warning
altogether (whether you use or not the destructured values).
The reason for removing the warning entirely is because (1) it's
simpler, but more so (2) there's no impact on the final code produced
_anyway_. Redundant let bindings are already removed by the compiler;
and while it's an implicit behaviour that requires a proper warning
when it's coming from a user-defined assignment; here the redundant
assignment is introduced by the compiler to begin with as another
implicit behavior!
So we have an implicit behaviour triggering a warning on another
implicit behaviour. Truth is, there's no impact in having those
parameters destructured and unused. So since users are already not
aware that this results in an implicit let assignment being inserted
in place for them; there's no need for the warning at all.
Avoid the interface to hang for several seconds without feedback when counterexamples are being simplified. This sends a heads-up to the user to indicate that a research of a counter example is going on.
KtorZ