-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename Carrier to Algebra. #285
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me so happy! Just a couple of suggestions.
@@ -85,7 +85,7 @@ runTeletypeIO :: TeletypeIOC m a -> m a | |||
runTeletypeIO = runTeletypeIOC | |||
``` | |||
|
|||
`Carrier`s are also `Monad`s. Since `TeletypeIOC` is just a thin wrapper around an underlying computation, we can derive several instances using `-XGeneralizedNewtypeDeriving`: | |||
Carrier types are also `Monad`s. Since `TeletypeIOC` is just a thin wrapper around an underlying computation, we can derive several instances using `-XGeneralizedNewtypeDeriving`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a particularly good case for the word 👍 nice.
@@ -2,7 +2,7 @@ | |||
|
|||
## Why are you reimplementing types equivalent to those provided by `transformers`? Why not use `StateT` instead of defining a separate `StateC` type? | |||
|
|||
Were we to reuse the `transfomers` interface, we would elide a few manual instances, but we would still require a newtype wrapper so as to avoid orphan `Carrier` instances, so the degree of reuse would be minimal. Additionally, in many cases, the `transformers` interface is not as good as it could be: it is an old and venerable library, under significant backwards-compatibility constraints. Defining new monads rather than reusing existing ones allows us to paper over many of the issues present in `transformers`, such as: | |||
Were we to reuse the `transfomers` interface, we would elide a few manual instances, but we would still require a newtype wrapper so as to avoid orphan `Algebra` instances, so the degree of reuse would be minimal. Additionally, in many cases, the `transformers` interface is not as good as it could be: it is an old and venerable library, under significant backwards-compatibility constraints. Defining new monads rather than reusing existing ones allows us to paper over many of the issues present in `transformers`, such as: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things are different since #226, so we should maybe revisit this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Not necessarily in this PR, mind you.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed this earlier as #284.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, lol, so you did 😂 ty!
Co-Authored-By: Rob Rix <robrix@github.com>
Co-Authored-By: Rob Rix <robrix@github.com>
Fixes #216.