search

kowainik / eio

🎯 IO with Exceptions tracked on the type-level
Mozilla Public License 2.0
58 stars 2 forks source link

Write custom type-errors #7

Open chshersh opened 3 years ago

chshersh commented 3 years ago

Currently the default GHC errors are produced, but we can do better with custom type errors. Probably even using the type-errors-pretty library.

JonathanLorimer commented 3 years ago

I'd be interested in helping out with this. I will have some time to put into this next week. I am just learning about custom type errors in Thinking With Types. Is there a small place that would be good for me to start on?

chshersh commented 3 years ago

@JonathanLorimer A good starting point would be to patch the runEIO function:

https://github.com/kowainik/eio/blob/4a09370351bd5a24754672853d1be147fa28ef52/src/EIO.hs#L65-L66

So instead of simply checking for an empty type-level list of exceptions, we can write a better custom error message in the spirit:

The 'runEIO' handler requires to handle all exceptions in 'EIO'.
But the action throws the following exceptions:

    * MyErr1
    * MyErr2
JonathanLorimer commented 3 years ago

I would like to use type-errors-pretty as you mentioned, but it is built with stack, which has 8.10.4 as its latest ghc version and eio uses 9.0.1. I am not sure if the compiler mismatch is a fatal error, but cabal is unable to solve the version constraints on base:

  -- eio.cabal
  build-depends:       base ^>= 4.15.0.0,

  -- type-errors-pretty.cabal
  build-depends:       base >= 4.10.1.0 && < 4.15

I am not really sure how to move a stack project beyond the nightly lts. Perhaps my first pass should just use the type error functions in GHC.TypeLits

JonathanLorimer commented 3 years ago

Alright, I put together a preliminary PR #13 . I tried to follow the style of your previous commits, but let me know if there is a CONTRIBUTING.md guide somewhere that I can follow.