We use `MProd` instead of `Prod` to group values when expanding the
`do` notation. `MProd` is a universe monomorphic product.
The motivation is to generate simpler universe constraints in code
that was not written by the user but generated by the `do` macro.
Note that we are not really restricting the macro power since the
`HasBind.bind` combinator already forces values computed by monadic
actions to be in the same universe.
The new test cannot be compiled without this modication.
The compiler frontend implemented in C++ is eagerly inlining local
functions. The new test would take an absurd amount of time without
the new hack.
We remove this hack when we re-implement the compiler frontend in Lean.
@Kha `withReader` is a well-behaved version of `adaptReader`. `adaptReader` is
too general, and it often produces counterintuitive elaboration
errors.
Here are two super annoying issues I hit all the time:
1- `adaptReader` + polymorphic code
```
def ex1 : ReaderT Nat IO Unit :=
adaptReader (fun x => x + 1) $
IO.println "foo" -- 3 Errors here failed to synthesize `Monad ?m` and `MonadIO ?m`, and don't know how to synthesize `Type → Type`
```
2- `adaptReader` and notation that requires the expected type
```
structure Context :=
(x y : Nat)
def ex2 : ReaderT Context IO Nat :=
adaptReader (fun s => { s with x := 10 }) $ -- Error at the structure instance
...
```
In the example above, I have to write `fun (s : Context) => ...` to
fix the problem.
The two problems above happen in the old and new frontends. However,
there is a new problem specific for the new frontend. In the new
frontend, a `do` is only elaborated when the expected type is known.
So, `adaptReader (fun ctx => ...) do ...` seldom works :(
As I said above, the issue is that `adaptReader` is too general. Its
type is
```
{ρ ρ' : Type u_1} → {m m' : Type u_1 → Type u_2} → [MonadReaderAdapter ρ ρ' m m'] → {α : Type u_1} → (ρ' → ρ) → m α → m' α
```
`withReader` is a simpler version of `adaptReader`
```
withReader : {ρ : Type u_1} → {m : Type u_1 → Type u_2} → [MonadWithReader ρ m] → {α : Type u_1} → (ρ → ρ) → m α → m α
```
It doesn't have any of the problems above. Moreover, I managed to replace
every single instance of `adaptReader` with `withReader` at the stdlib
and tests. We don't need the `adaptReader` generality.
@Kha I did not implement support for reassignments and `continue`,
`break`, `return` inside the `finally` clause. It is doable, but it
feels like unnecessary complexity. We currently don't have any
instance in our code base where this would be useful.
@Kha The Rust `let+return` example works in Lean too :)
The Rust function
```rust
fn f (x : i32) -> i32 {
let y = if x == 0 { println!("x is zero"); return 100 } else { x + 1 };
println!("y: {}", y)
y
}
```
The Lean version is
```lean
def f (x : Nat) : IO Nat := do
let y ← if x == 0 then IO.println "x is zero"; return 100 else pure (x + 1)
IO.println ("y: " ++ toString y)
return y
```
The main missing feature now is the `try-catch-finally` `do` element.
@Kha we are getting better error message, but we need to figure out a
way to suppress error messages that come from the "plumbing".
For example, in the following example.
```
def f4 (b : Bool) (n : Nat) (v : Vector Nat n) : Vector Nat (n+1) := do
if b then
v := Vector.cons 1 v
Vector.cons 1 v
```
We get the nice "invalid reassignment" error at `v := ...`, but
we also get the nasty
```
error: application type mismatch
jp✝ v
argument
v
has type
Vector Nat (n + 1)
but is expected to have type
Vector Nat n
failed to synthesize instance
CoeT (Vector Nat (n + 1)) v (Vector Nat n)
```
Where `jp✝` is a joinpoint created by the do-notation macro expander.
I thought about using `withoutErrToSorry` when elaborating the expanded
`do` term.
We may also try to add more helper hints such as `ensureTypeOf!` and
use them around "plumbing" code (e.g., "joinpoint goto"s)
