search

cdepillabout / servant-checked-exceptions

type-level errors for Servant APIs.
https://hackage.haskell.org/package/servant-checked-exceptions
BSD 3-Clause "New" or "Revised" License
73 stars 14 forks source link

Relax unnecessary kind constraint. #33

Closed fisx closed 5 years ago

fisx commented 5 years ago

If you don't have this constraint, you can do fun things like using the integer literals of status codes as error types.

Whether one thinks that's a good idea or not, the proposed change should be harmless.

cdepillabout commented 5 years ago

@fisx Thanks for taking the time to send this PR.

While it would be possible to make this change (as well as changing Throwing to data Throwing (e :: [k])), I don't think it would be possible to actually use Throws with anything other than kind *.

In practice, the HasServer instances for Throwing es turn it into a type like Handler (Envelope es a). Envelope forces the es to be kind [*], so it is not possible to use any other kind.

I think keeping the kind of the argument on Throws as * makes it a little easier to see how it should be used when you're looking through the haddocks.

Are you trying to use Throws somewhere other than just the provided HasServer or HasClient instances provided by these packages?

fisx commented 5 years ago

Hum, I changed my mind.

I"m confident that there is a reasonable way to support Throws 401. I was hoping this would be a trivial change, but it looks like it's not, and I agree that it's nice to have the * in the haddocks easy understandability.

Sorry for noise and thanks for the feedback! :)

(Is it indicative of a gap in the test suite that my change didn't trigger a failure? I guess not. You could construct a type error and assert that it fails to type check, but that seems weird somehow.)

cdepillabout commented 5 years ago

I'm confident that there is a reasonable way to support Throws 401

I'd be interested if you could figure out a good way to support something like this. I think the inner workings of the Throws (and Throwing) types might need to be reworked a little bit.

Is it indicative of a gap in the test suite that my change didn't trigger a failure? I guess not. You could construct a type error and assert that it fails to type check, but that seems weird somehow.

Yeah, I guess should-not-typecheck could be used here, but I currently don't have any type-level tests setup for servant-checked-exceptions like that.