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

AccumT is a regular transformer and should have a regular MonadAccum instance. #141

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jumper149
Copy link

I think this was accidentaly copy-pasted, see #140 .

I don't see any problem with doing it this way.
Maybe you can spot anything?

@jumper149
Copy link
Author

Moving this here just so that it doesn't get lost (from #140):

Edit: I don't understand why the MonadAccum instance for AccumT also uses Identity as a base monad. I think it should be fine with any monad, right?

Not unless you want to overlap on the monoid instance. Every Monad may admit any number of accumulating monoids, so the general instance is not supplied. This is a case where we ask not "can we?" but "should we?".

This discussion should move to #141.


My motivation was WriterT in this case.

instance (Monoid w, Monad m) => MonadWriter (WriterT w m)

I also feel like this is the way, that all transformers instances work (except for SelectT).
Even ContT is sort of like that.


So if you would argue to keep Monoid w => MonadAccum w (AccumT w Identity), then you should also argue for Monoid w => MonadWriter (WriterT w Identity), right?

Well I think the way that WriterT does it currently is better.

There is no reason to restrict this instance any further.
@emilypi
Copy link
Member

emilypi commented Jan 14, 2023

My motivation was WriterT in this case.
I also feel like this is the way, that all transformers instances work (except for SelectT).
Even ContT is sort of like that.

Sorry, I'm confused as to why you feel this is "the way"? What way? Are you making the argument that it's always the case that (Monoid w, Monad m) => work as constraints for Writer and Accum? Have you checked the laws? I'm finding that (->) t is a counter example to the laws for MonadAccum for all monoids except (). I suspect that this is the case for Writer as well, but I'll have to write the equations down.

If this is not the case and you've found a way to make it work, do you mind presenting your work and showing us that the laws pass?

@jumper149
Copy link
Author

Have you checked the laws?

I did the work: https://felixspringer.xyz/homepage/blog/accumtsMonadaccumInstance


I'm finding that (->) t is a counter example to the laws for MonadAccum for all monoids except ().

I didn't check this in particular, but considering that I just proved it for any base monad your finding cannot be true (unless I made a mistake of course, so please thoroughly check it).

@Lysxia
Copy link

Lysxia commented Jan 14, 2023

This looks like a fine change to me. I'm also puzzled why Identity is in this instance in the first place.

@emilypi
Copy link
Member

emilypi commented Jan 15, 2023

@jumper149 I believe i was looking at the PR last night and proved something else for something entirely unrelated to the PR. I checked again and yes, your proof is fine, thanks for providing it. It seems like this would be fine!

@Futarimiti
Copy link

Any updates on this? I wonder why is this not merged still after 2 years

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.

5 participants