This new flag determines whether we should introduce a new kind to
represent lambda sets, or whether lambdas should be erased. The latter
is not yet implemented.
Previously, we would drop uninhabited captures from lambda sets' runtime
representations, which meant sets like
```
[L1 {a: Str}, L2 {a: []}]
```
had runtime representation
```
{Str}
```
rather than
```
Union({Str}, {[]})
```
if we drop unreachable lambdas from the representation, then the
reachable lambdas are somewhat more efficient to compile (as there are
less material tag options), but the compiler complexity increases
because we must represent voided capture sets in the lambda set.
Even if a lambda has voided captures, we must specialize it, because
failing to do so opens us up to losing relevant specializations needed
later on. See 2f7020aa31 for a
previous occurence of that.
As such, simply keep voided layouts in place during lambda set
compilation. The optimizer should elide them anyway.
If an entry in the layout cache contains recursive structures, the entry
is not reusable if the recursive structure is currently in the "seen"
set. The example elucidated in the source code is as follows:
Suppose we are constructing the layout of
```
[A, B (List r)] as r
```
and we have already constructed and cached the layout of `List r`, which would
be
```
List (Recursive [Unit, List RecursivePointer])
```
If we use the cached entry of `List r`, we would end up with the layout
```
Recursive [Unit, (List (Recursive [Unit, List RecursivePointer]))]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cached layout for `List r`
```
but this is not correct; the canonical layout of `[A, B (List r)] as r` is
```
Recursive [Unit, (List RecursivePointer)]
```
However, the current implementation only preserves this behavior for
structures that contain one recursive structure under them. In practice,
there can be structures that contain multiple recursive structures under
them, and we must be sure to record all those structures in the
layout-cache.
With a code like
```
thenDo = \x, callback ->
callback x
f = \{} ->
code = 10u16
bf = \{} ->
thenDo code \_ -> bf {}
bf {}
```
The lambda `\_ -> bf {}` must capture `bf`. Previously, this would not
happen correctly, because we assumed that mutually recursive functions
(including singleton recursive functions, like `bf` here) cannot capture
themselves.
Of course, that premise does not hold in general. Instead, we should have
mutually recursive functions capture the closure (haha, get it) of
values captured by all functions constituting the mutual recursion.
Then, any nested closures can capture outer recursive closures' values
appropriately.
