Now, the elaborator only uses the quasi-pattern unifier approximation
for inferring the implicit motive in recursor-like applications.
This change was motivated by counterintuitive behavior associated with
this approximation. For example, before this commit
```
variables {δ σ : Type}
def ex1 : state_t δ (state_t σ id) σ :=
monad_lift (get : state_t σ id σ) -- doesn't work
def ex2 : state_t δ (state_t σ id) σ :=
do s ← monad_lift (get : state_t σ id σ), -- works
return s
```
The first one doesn't work because when we elaborate
`@monad_lift ?m ?n ?c ?α (get : state_t σ id σ) : ?n ?α`
with expected type `state_t δ (state_t σ id) σ`
It first produces the following unification problem by processing
matching the inferred type with the expected one.
```
?n ?α =?= state_t δ (state_t σ id) σ
==> (approximate using first-order unification)
?n := state_t δ (state_t σ id)
?α := σ
```
Then we try to solve
```
?m ?α =?= state_t σ id σ
==> instantiate metavars
?m σ =?= state_t σ id σ
==> (approximate since it is a quasi-pattern unification constraint)
?m := λ σ, state_t σ id σ
```
Remark: the constraint is not a Milner pattern because `σ` is in
the local context of `?m`. By assuming it is a Milner pattern,
we are ignoring the other possible solutions:
```
?m := λ σ', state_t σ id σ
?m := λ σ', state_t σ' id σ
?m := λ σ', state_t σ id σ'
```
We need the quasi-pattern approximation for elaborating recursors.
So, this commit enable this kind of approximation only when
elaborating recursors and executing induction-like tactics.
If we had used first-order unification, then we would have produced
the right answer: `?m := state_t σ id`
Haskell would solve this example since it always uses
first-order unification during elaboration.
The second one works because when we elaborate
`monad_lift (get : state_t σ id σ)`, the expected type is `state_t δ (state_t σ id) ?α`.
So, `?m ?α =?= state_t σ id σ` will not considered to be a quasi-pattern
since `?α` is not yet assigned to a local constant.
We are not fully confident this commit produces a better user
experience. We know that
- Full higher-order unification (used in Lean2) produces a combinatoric
explosion, and generates a lot of non-termination in complex type class
hierarchies (monad library, has_coe, etc). The problem is that
higher-order unification manages to create new solutions that we
cannot find using first-order unification.
- Lean3 is more reliable than Lean2 for elaborating monadic code because
it does not use higher-order unification.
- For elaborating recursor-like applications, we need at least the
quasi-patterns. We need it when trying to infer the implicit
motive. First-order unification works poorly in this case. Note that
the lack of higher-order unification in Lean3 forces us to provide the
motive explicitly for terms that Lean2 can elaborate.
- We need quasi-patterns for solving unification constraints in the
induction-like tactics. Similar to the previous item. We use it to infer
the motive. (edited) I will try to disable the quasi-pattern
approximation when elaborating regular applications. At least, we will
behave like Haskell for this kind of application.
Before this commit, the unifier would try to solve the unification consraint
?m =?= fun x_1 ... x_n, ?m x_1 ... x_n
by assigning
?m := fun x_1 ... x_n, ?m x_1 ... x_n
which fails the occurs check.
This commit skips the assignment by using eta-reduction.
@nunoplopes @aqjune
I had to add a new primitive to allow you to execute a tactic from the
`main` function. The `main` function is in the `io` monad. The new
primitive has type:
```
meta constant io.run_tactic {α : Type} (a : tactic α) : io α
```
I also added a new test that shows how to use it.
The test displays all declarations that have the `nat` prefix.
cc @kha
@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
@aqjune @nunoplopes: This commit adds basic support for random numbers.
It defines a random number generator interface, and an basic
implementation based on the Haskell one.
We can add more implementations in the future if neeeded.
The new test program has a few examples.
BTW, this is a pure Lean implementation.
If we need more performance we can provide an implementation
using C++.
@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.
@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.
