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.
@Kha The motivation is to allow users to define default instances such as
```lean
@[defaultInstance 1]
instance : OfScientific Real where
...
```
Then, numerals such as `1.2` and `3.4e10` will be `Real` by default instead of `Float`.
@Kha I had a few issues similar to the `Append` issues.
We used a similar idiom for writing builtin parsers where we may write
```
def p : Parser := "foo " >> "bla "
```
as a shorthand for
```
def p : Parser := symbol "foo " >> symbol "bla "
```
I want to support `builtin syntax` one day :)
That being said, we should decide whether we keep `HAppend`, `HOrElse`,
and `HAndThen` or not.
The only one I wish I had in the past is `HAndThen`.
@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 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`.
@Kha I was tired of writing `arbitrary _` :)
There 0 places in the stdlib where the type needs to be provided.
If in the future we need to specify the type we can use
`arbitrary (α := <type>)`
