@kha I have added a few performance counters.
I collect their values at each snapshot.
Right now, I am printing only the values in the last snapshot, but if we want
we can even display their progress over time.
Right now, I track the following information
- number of allocated closures
- number of allocated constructors/objects
- number of allocated big numbers
@aqjune @nunoplopes: See new tests at tests/lean/run/random.lean
We have two actions in `io`. By default, `io` uses the C++
random number generator, but we can force it to use a `std_gen` with
the action `set_rand_gen`.
def rand (lo : nat := std_range.1) (hi : nat := std_range.2) : io nat
def set_rand_gen : std_gen → io unit
This reverts commit 18c2e3739a.
The change introduced a bug where a .olean file may have been saved even if
the corresponding module had produced errors during processing, as long as these
errors were not part of the current region of interest.
@kha We can now solve unification constraints of the form
?m unit =?= itactic
I'm not very confident this new extension will improve usuability
instead of creating new counter-intuitive behavior.
At least, in the process of implementing it, I fixed two bugs,
and removed a nasty hack that was being used in the unifier.
Thus, even if we disable this feature in the future, some good came out
of it.
Although, the new extension locally increases the number of constraints
that can be solved, it may prevent terms that could be elaborated before
from being elaborated. I am not too concerned at this point because
I could not construct a natural example. I encountered one case, but it
was due to a problem that I fixed in the previous commit.
I reconstruct it here for the record. Suppose we have a constraint
?m_1 ?m_2 =?= itactic
Without the fix from the previous commit, `itactic` would unfold too
`id_rhs Type (tactic unit)`, and the constrain would be solved as
?m_1 := (id_rhs Type)
?m_2 := (tactic unit)
It succeeds locally, but the elaboration fails later when it tries to
synthesize the type class `has_bind (id_rhs Type)`.
The previous fixes the problem by making sure `itactic` is unfolded to
`tactic unit` as expected. `id_rhs` is an auxiliary definition
used to implement smart unfolding. That being said, the user could in
principle define `itactic` as `@id Type (tactic unit)`, and the constraint
?m_1 ?m_2 =?= itactic
will be solved as
?m_1 := (@id Type)
?m_2 := (tactic unit)
which is not the solution we want.
This commit removes a hack that forced first-order unification
to be used to solve unification constraints of the form
?m a =?= f ?x
during elaboration. The hack force first-order unification
even when `?m a` is a higher order pattern and a precise solution
exists.
Moreover, the example that motivated that hack is not applicable
anymore since the type class `has_mem` is now defined as:
```
class has_mem (α : out_param $ Type u) (γ : Type v) := (mem : α → γ → Prop)
```
instead of
```
class has_mem (α : Type u) (γ : Type u → Type v) := (mem : α → γ α → Prop)
```
cc @kha
@kha This commit fixes the bug we discussed on slack.
I had to repair one of the tests. The broken test made me
realize that if we use the unbundled approach to define something like
`is_semiring`
```
class is_semiring (α : Type) (plus : α → α → α) (mul : α → α → α) (zero : out_param α) (one : out_param α) :=
...
```
Then, to retrieve a `is_semiring` instance, we need to know `α`, `plus`
and `mul`. This is problematic because we may be in a context where one
of them cannot be inferred. This would force user to manually provide
the missing (input) parameter. We are not considering the unbundled
approach for complex algebraic structures such as `semiring`, `ring` and
`field`, but I wanted to document this limitation here since we may face
it in other type classes.
I think it is a bad idea to add back `inout_param` and have both:
`inout_param` and `out_param`. The previous `inout_param` created
many instabilities and hard to diagnose failures.
