* Use cabal-doctest
- Haskell build tools run in slightly different environments (meaning different
package databases are available).
- The nixpkgs build for polysemy-plugin is failing due to a missing package
database, which causes the doctest to fail (more information here:
https://github.com/NixOS/nixpkgs/issues/71164).
- By using cabal-doctest we can expose the Haskell packages required to the
doctests no matter the build tool we're using.
* Use cabal-doctest in polysemy, build on GHC 8.8.1
- Use @googleson78 's changes to build polysemy on GHC 8.8.1, with slight
modifications. The source distribution is now found in "dist-newstyle/sdist",
so we've updated the command to point at that folder. Additionally, cabal
v2-install doesn't support installing .tar.gz files in the same way v1-install
did, so updated the command to use "cabal v1-install".
- Modified polysemy to use "cabal-doctest" and so overcome issues with the
doctest tests (see issue #258, PR #265).
In interpreter mode, the plugin used to see rows like State (Identity a) ': State a ': r, with an action in State a, and then incorrectly unify that thing with the first thing in the list State (Identity a). As a result, we'd ask for Identity a ~ a, which is infinite, and things would go wrong.
Now we instead collect all of the unifications we'd like to do, and only emit the most specific one, as measured by number of type constructors in it. This will now only emit a State (Identity a) ~ State (Identity s), and then unify the state we're looking for, plus the a ~ s that solves the other state action.
But the next problem is that we can't determine IndexOf in the row above, because a is a type variable, and so IndexOf is stuck, even though we know IndexOf that_row (State a) ~ 'S 'Z. So the plugin now also solves "stuck" IndexOfs of that form.
All of this means we can now happily introduce local effects that have type variables, for effects that are already known to be present in the row. And somehow it just works! Amazing!
* Move Polysemy.Internal.Lift to Polysemy.Lift.Type
* Add Polysemy.Lift module and runLift interpreter
* Add a Sandy reminder
* Add explicit foralls and split type signature
* Fix import spacing, for there is no "qualified"
* Implement runIO in terms of runLift
* Rename Lift -> Embed
* Replace sendM with embed
* Add a Sandy todo for embed version
* Rename runEmbed and related runEmbedded (from IO)
* runEmbedded -> runEmbeddedInIO
* runEmbed -> runEmbedded
* Update cabal
This PR changes the plugin so it will notice an insoluble constraint of the form Sem r a ~ Foo, and mark that r takes part in a genuine type error. The plugin will then provide a bogus evidence term for IfStuck (IndexOf r _) _ _, which prevents the AmbiguousSend error message from firing.
* Remove explicit loopbreakers, enable plugin
* Use uploaded version of `loopbreaker`
* Fix span of macro
* Disable plugin on GHC <8.6
* Add comment about use of plugin
* Separate unrelated conditions
This PR provides a single function withLowerToIO, which runs a desired Sem r effect all the way down to IO, without needing to know the natural transformation beforehand. It does it by running the desired code in a new thread, and shipping all of the unhandled effects back to the main thread. The main thread turns into an event loop for the duration of the withLowerToIO block.
This thing was a vestige of the bad old days when you had to write
*instances* of classes things in Polysemy. It was a terrible experience,
and so we don't do that anymore. As a result, the only two instances of
`Effect` were for `Union` and `Yo` --- so I just inlined them.
This PR adds doctests allowing us to write tests for the custom type errors. Having this stuff reified in the test suite means we can iterate on the implementations and give much better QA.
* Allow bidirectional typechecking in the plugin
The plugin used to choke on this:
```haskell
flipShouldBe 11 . sum . fst . run . runFoldMapOutput id $ do
output [1]
output $ replicate 2 5
```
because it would fail to unify `Output (t Int)` (the polymorphic
`Traversable` variable in `sum`) with `Output [Int]`.
In this case, there are no given constraints, so the plugin is
attempting to solve a `Member (Output (t Int)) '[Output [Int]]`. We
reuse the codepath for unifying wanted/givens, pretending like the
`Output (t Int)` is a given.[^1]
[^1]: Pretending it's a wanted breaks something else that I don't
remember right now. This code is brittle :(
So now we have a "wanted" `Output [Int]`, and a "given" `Output (t
Int)`. In general, this thing isn't OK to solve. Consider a real
example:
```haskell
foo :: Member (Output (t Int)) r => Sem r ()
foo = output [5]
```
This is a type error, because the polymorphism goes the wrong way. We
have no guarantees that `t` is supposed to be `[]`.
But in our original example, this isn't a problem, because our `t` isn't
actually in given position. It's just an artifact of reusing the code!
`mkWanted` now takes a new parameter for whether or not it's OK to allow
the givens to be polymorphic.
Such a thing necessitates a change though. We never want to unify
a polymorphic *effect* in given position. Doing so will break Haskell's
regular type inference that determines what the effect row should be,
based on the order in which the interpreters are run.
* Ensure wanted constraints are emitted only once.
This is a fix for the "solveSimpleWanteds: too many iterations" problem
that people are running into. In these cases, the plugin is being asked
to solve the same `Member` constraint several times, and generating
a new wanted each time. In doing so, GHC thinks that work was done, so
it will ask the plugin to run again next time. This process diverges,
and produces the error.
Fixes#79
