Commit graph

18 commits

Author SHA1 Message Date
Sebastian Ullrich
0c91b3769e chore: replace variables in src/ 2021-01-22 14:36:05 +01:00
Leonardo de Moura
e6215f7282 chore: remove some unnecessary commas 2020-11-20 15:47:27 -08:00
Leonardo de Moura
91dca53274 refactor: remove MonadIO
There is no reason for having `MonadIO` anymore. The `MonadLift` type
class is well behaved in the new frontend, the `MonadFinally` solves
the problem at monad stacks such as `ExcepT e IO`.

This commit also changes the type of the IO printing functions.
For example, the type of `IO.println` was
```
def IO.println {m} [MonadIO m] {α} [ToString α] (s : α) : m Unit
```
and now it is just
```
def IO.println {α} [ToString α] (s : α) : IO Unit
```
We rely on the new frontend auto-lifting feature.
That is, if there is an instance `[MonadLiftT IO m]`, then
a term of type `IO a` is automatically coerced to `m a`

We also want a simpler `IO.println` for writing tests.
For example,
```
```
doesn't work because there isn't sufficient information for inferring
the parameter `m` in the previous `IO.println`.
The shortest workaround looked very weird
```
```

I considered adding `IO` as a default value for `m` when we have
`MonadIO m`, as we use `Nat` as the default for `ofNat a`, but it felt
like uncessary complexity.

@Kha The commit seems to work well. The auto-lifting featuring has
been working great for me. There is still room for improvement.
For example, given `MonadLiftT m n`, it doesn't automatically lift
`a -> m b` into `a -> n b`. So, code such as
`foo >>= IO.println`
had to be rewritten as
`foo >>= fun x => IO.println x`
I will add this feature later.
If you have time, please try to play with this feature and figure out
if it is stable enough for making it the default.
That is, if it roboust enough, we can stop using the following idiom
for writing functions that can be lifted automatically.
```
def instantiateLevelMVarsImp (u : Level) : MetaM Level :=
  ...

def instantiateLevelMVars {m} [MonadLiftT MetaM m] (u : Level) : m Level :=
  liftMetaM $ instantiateLevelMVarsImp u
```
I think we only need this idiom when using `MonadControlT` which is
not as common as `MonadLiftT`.
2020-11-18 18:47:22 -08:00
Leonardo de Moura
633578cfaf chore: use StateRefT macro 2020-10-27 13:05:12 -07:00
Leonardo de Moura
13c2a8ff51 chore: remove #lang lean4 header 2020-10-25 09:54:07 -07:00
Leonardo de Moura
5c58d77836 chore: move to new frontend 2020-10-23 12:53:19 -07:00
Leonardo de Moura
02521397ac refactor: rename MonadExceptOf.catch => MonadExceptOf.tryCatch 2020-10-22 17:27:15 -07:00
Leonardo de Moura
a37e2ae46f refactor: simplify MonadFunctor 2020-10-22 17:05:34 -07:00
Leonardo de Moura
321719b300 feat: add MonadFinally 2020-08-25 17:58:35 -07:00
Leonardo de Moura
1103806ff4 refactor: HasMonadLift ==> MonadLift 2020-08-25 13:54:41 -07:00
Leonardo de Moura
b03cd748cf feat: add MonadControl 2020-08-25 13:54:41 -07:00
Leonardo de Moura
d85836a387 chore: mark TODO 2020-08-23 19:55:53 -07:00
Leonardo de Moura
77b9445544 feat: real ST monad
@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.
2020-08-23 12:15:32 -07:00
Leonardo de Moura
fad6235abb feat: give a name to EIO Empty
@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 }
```
2020-08-20 15:47:27 -07:00
Leonardo de Moura
968457ac1c feat: make sure StateRefT can be used with any base EIO Exception 2020-08-20 13:11:12 -07:00
Leonardo de Moura
64f5ac37c1 fix: missing instance 2020-08-18 17:22:22 -07:00
Leonardo de Moura
58c4d8bfc0 refactor: add MonadStateOf
@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]`
2020-08-18 16:35:33 -07:00
Leonardo de Moura
f01d45a6c1 feat: add StateRef 2020-08-18 13:54:51 -07:00