Skip to content
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

Merged
merged 6 commits into from
Oct 22, 2019
Merged

Rename Carrier to Algebra. #285

merged 6 commits into from
Oct 22, 2019

Conversation

patrickt
Copy link
Collaborator

Fixes #216.

@patrickt patrickt requested a review from robrix October 21, 2019 17:36
Copy link
Contributor

@robrix robrix left a 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.

docs/common_errors.md Outdated Show resolved Hide resolved
docs/common_errors.md Outdated Show resolved Hide resolved
@@ -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`:
Copy link
Contributor

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:
Copy link
Contributor

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.

Copy link
Contributor

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.)

Copy link
Collaborator Author

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.

Copy link
Contributor

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!

patrickt and others added 3 commits October 21, 2019 20:55
Co-Authored-By: Rob Rix <robrix@github.com>
Co-Authored-By: Rob Rix <robrix@github.com>
@robrix robrix merged commit c342241 into master Oct 22, 2019
@robrix robrix deleted the carrier-to-alg branch October 22, 2019 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Carrier is a poor name for the typeclass
2 participants