9338aabed9
This PR changes the interface of the `ForIn`, `ForIn'`, and `ForM` typeclasses to not take a `Monad m` parameter. This is a breaking change for most downstream `instance`s, which will will now need to assume `[Monad m]`. The rationale is that if the provider of an instance requires `m` to be a Monad, they should assume this up front. This makes it possible for the instanve to assume `LawfulMonad m` or some other stronger requirement, and also to provided a concrete instance for a particular `m` without assuming a non-canonical `Monad` structure on it. Zulip: [#lean4 > Monad assumptions in fields of other typeclasses @ 💬](https://leanprover.zulipchat.com/#narrow/channel/270676-lean4/topic/Monad.20assumptions.20in.20fields.20of.20other.20typeclasses/near/537102158)
37 lines
833 B
Text
37 lines
833 B
Text
-- Tests the `monotonicity` tactic
|
|
|
|
/-
|
|
Should test that the tactic syntax is scoped, but cannot use #guard_msgs to catch “tactic not known”
|
|
errors, it seems:
|
|
|
|
/--
|
|
error: unsolved goals
|
|
⊢ True
|
|
-/
|
|
#guard_msgs in
|
|
example : True := by monotonicity
|
|
|
|
-/
|
|
|
|
open Lean.Order
|
|
|
|
example : monotone (fun (f : Nat → Option Unit) => do {do f 1; f 2; f 3}) := by
|
|
repeat monotonicity
|
|
|
|
example : monotone (fun (f : Option Unit) => do {do f; f; f}) := by
|
|
repeat monotonicity
|
|
|
|
example : monotone
|
|
(fun (f : Nat → Option Unit) => do
|
|
for x in [1,2,3] do f x : _ → Option _) := by
|
|
repeat' monotonicity
|
|
|
|
example : monotone
|
|
(fun (f : Nat → Option Nat) => do
|
|
let mut acc := 0
|
|
for x in [1,2,3] do
|
|
acc := acc + (← f x)
|
|
if acc > 10 then
|
|
return 5
|
|
pure acc : _ → Option _) := by
|
|
repeat' monotonicity
|