In the new frontend,
```lean
@[macroInline] def or : Bool → Bool → Bool
| true, _ => true
| false, b => b
```
is compiled as
```lean
def or (x y : Bool) : Bool :=
or.match_1 _ x y (fun _ => true) (fun b => b)
```
Thus, the `[macroInline]` attribute does not guarantee that `y` is
evalutated only when `x` is `false`. The new definition does.
This issue was not exposed before because the compiler has an
optimization that float let-decls when they are used in a single
branch.
@Kha We have talked about removing `macroInline`, and defining
functions such as `or` as
```lean
@[inline] def or (x : Bool) (y : Unit -> Bool) : Bool :=
match x with
| true => true
| false => y ()
```
and define `x || y` as notation for `or x (fun _ => y)`.
I think this is the way to go for polymorphic operators such as `<|>`,
but I am not sure about `or`. New users will probably be puzzled by
it. In particular when they are writing proofs.
After this commit, we have to use an explicit `discard` in code such as
```
def g (x : Nat) : IO Nat := ...
def f (x : Nat) : IO Unit := do
discard <| g x -- type error without the `discard`
IO.println x
```
Motivation: prevent users from making mistakes such as
```
def f (xs : Array Nat) : IO Unit := do
xs.set! 0 1
IO.println xs
```
when they meant to write
```
def f (xs : Array Nat) : IO Unit := do
let xs := xs.set! 0 1
IO.println xs
```
Before this commit, the threshold was the amount of "fuel".
Now, it is the maximum number of instances used to solve a TC problem.
We have two thresholds
- `maxInstSize`: default 128
- `maxCoeSize`: default 16. It is similar to `maxInstSize`, but used for automatic coercions.
cc @Kha
@Kha This one required a bunch of manual fixes. The main issue is that
before we added the string interpolation feature, we created
`MessageData`s using `++` and coercions. For example, given
`(e : Expr)`, we would write
```
let msg : MessageData := "type: " ++ e
```
and rely on the coercions `String -> MessageData` and
`Expr -> MessageData`, and the instance `Append MessageData`.
However, heterogeneous operators "block" the expected type propagation downwards.
This kind of code is obsolete now since we can write a more compact
version using string interpolation
```
let msg := m!"type: {e}"
```
@Kha The new `rational.lean` test shows their usefulness. We just
define the monorphic version and a coercion, and get a bunch of `HAdd`
instances for free.
@Kha I had some unexpected surprises, but it is a good change.
Here is the summary.
1- We could get rid of `a %ₙ b` and `ModN` class. We can use `HMod`
instead. It was a positive surprise since I didn't remember we had
this `ModN` class.
2- Coercions are never used in heterogeneous operators. This is
expected since `a * b` is now notation for `HMul.hMul a b`, and
`a` and `b` may have different types. I manually added instances such
as `HMul Nat Int Int`. However, I did not try to add generic instances
such as
```
instance [Coe a b] [Mul b] : HMul a b b where
hMul x y := mul (coe x) y
```
I will try later.
3- Give `h : cs.size > 0`, I got a type error at
```
let idx : Fin cs.size := ⟨cs.size - 1, Nat.predLt h⟩
```
`Nat.predLt h` has type `Nat.pred cs.size < cs.size`
However, `Nat.pred cs.size` doesn't unify with `cs.size - 1`.
The problem is that we can't synthesize the `HSub` instance until
we apply the default instances.
It worked before because `isDefEq` would force the pending TC
problem `Sub Nat` to be resolved, and after that we would be able
to reduce `cs.size - 1` and establish that it is definitionally
equal to `Nat.pred cs.size`.
I considered two possible workarounds
a) `let idx : Fin cs.size := ⟨cs.size - (1:Nat), Nat.predLt h⟩`
b) `let idx : Fin cs.size := ⟨cs.size - 1, by exact Nat.predLt h⟩`
The first one works because we are not providing enough information
for synthesizing the `HSub` instance. The second works because it
postpones the elaboration of `Nat.predLt h`. The default instances
will be applied before we start applying tactics.
4- The `.` notation is affected too. For example, `(x + 1).toUInt8`
doesn't work since we don't know the type of `x+1` until we apply
default instances. I fixed it by using `(x + (1:Nat)).toUInt8`.
Another possible fix is `Nat.toUInt8 (x + 1)`.
Similarly, `(x+1).fold ...` doesn't work.
5- The following code failed to be elaborated
```
indent (push s!"{ss'}\n") (some (0 - Format.getIndent (← getOptions)))
```
It was working before, but it relied on how the expected type is
propagated. The elaborator process
```
some (0 - Format.getIndent (← getOptions))
```
with expected type `(Option Int)`. So, the `-` is interpreted as
`Int.sub` although `Format.getIndent (← getOptions)` has type `Nat`.
In the new `HSub`, the expected type doesn't really influence TC
resolution since it is an `outparam`. So, we failed with the error
failed to synthesize `HSub Nat Nat Int`.
One possible fix was to add the instance `HSub Nat Nat Int` with
`Int.sub`, but I used the following fix
```
some ((0 : Int) - Format.getIndent (← getOptions))
```
which makes it clear that we want the `Int.sub` operator instead of
`Nat.sub`.
