@Kha: the new `ST` (and `EST`) are escapable like the Haskell ST monad.
It makes `StateRefT` much more useful because we can now run it from pure
code.
@Kha I am calling it `ST` for lack of a better name. It makes some
sense since only the `IO.Ref` operations are in `EIO Empty` :)
That being said, it may confuse Haskell users.
BTW, I had to give the name to avoid a nontermination in the TC
procedure when using
```lean
instance EIOEmpty.monadLift {ε} : HasMonadLift (EIO Empty) (EIO ε) :=
{ monadLift := fun α => fromEmptyEIO }
```
`reset` was used to implement a "buggy" `IO.ref.modify`.
```lean
@[inline] def Ref.modify {α : Type} (r : Ref α) (f : α → α) : m Unit := do
v ← r.get;
r.reset;
r.set (f v)
```
`IO.Ref.reset` will store a nullptr in `r`.
Now, suppose another thread tries to read this reference,
it will get an `IO.error`.
It is not a crash, but it is really weird behavior.
@Kha I am reverting this change for now.
I understand that the "default-value" approach is bad for debugging,
and it does not produce good error messages, but at least the frontend
will not "panic" when users add a bad macro.
After we switch to the new frontend, we can have a monadic `getArg`
and `getArgs` in the Elab and Macro monads which produces an
"unexpected syntax" error message. I say we wait for the new frontend
because we will be able to write `(<- s.getArg)` inside of
expressions.
@Kha I tried to remove `MonadExceptOf` by adding `HasThrow` and
`HasCatch`, but this change impacts our ability to define polymorphic
methods such as `finally` which is parametrized by `[MonadExcept]`.
If we remove the `outParam` from `[MonadExcept]`, then we will need to
know the exception at `finally`, or add two instances `[HasCatch]` and
`[HasThrow]`. So, it seems it is more convenient to have
`[MonadExceptOf]` and `[MonadExcept]`. Thus, I applied this approach
to `[MonadState]`
We add helper classes with `outParam`.
@Kha This is similar to the `MonadExceptOf` modification.
Motivation: the new `StateRefT` (state monad implemented using
`IO.Ref`) makes is it quite cheap to have multiple states on the
stack. But, we need a mechanism for accessing the different states in
a convenient way.
Note that, I did not add a `MonadStateOf` class, but helper classes
such as `HasGet` which uses `outParam`. I will do the same for `MonadExcept`.
Summary:
- `get` gets the state on the top of the Monad stack
- `getThe σ` gets the state with type `σ`
- `modify f` modifies the state on the top of the Monad stack.
We use `modify fun s => { s with ... }` quite often, and we cannot
infer type of `s` here.
- `modifyThe σ f` allows us to select which state on the stack we are modifying.
- I didn't add `setThe`, since we usually can infer the state type at
`set s`. In the whole codebase, we have only one instance where this
is not true.
@Kha I had to do this because of the `ident` vs `Term.id` recurrent
issue. `match_syntax` fails if a `Term.id` is used at `Term.letIdDecl`
where an `ident` is expected.
We should try to remove `Term.id` in the future.
