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

Fix ST-related problems with Frozen dataty #71

Conversation

Shimuuar
Copy link

@Shimuuar Shimuuar commented Apr 4, 2020

Another attempt to fix problems with Frozen discussed in #56, #67

Unlike previous attempt it does maintain injectivity and allows to work with ST
monad without any problems. MonadRandom's first type has * -> * kind.

Key idea is that for mutable PRNG state token variable is determined by monad
and for pure PRNG state var does not matter so we can pick anything, say ().

RE naming. I run out of good names so I picked Tok. Naming suggestions are greatly appreciated.

Also I think it would be desirable to flip Frozen data family. Instead of mutable generator and its frozen state we should have frozen generator and its mutable version. That will allow to 1) make MonadRandom instances for pure PRNG 2) possibly will allow to generalize runPrimGenST & Co.

Unlike previous attempt it does maintain injectivity and allows to work with ST
monad without any problems. MonadRandom's first type has * -> * kind.

Key idea is that for mutable PRNG state token variable is determined by monad
and for pure PRNG state var does not matter so we can pick anything, say ().
@lehins
Copy link
Collaborator

lehins commented Apr 4, 2020

I really don't think s inside Frozen is a problem, especially not enough to warrant such ugliness as PureGen g () and g (Tok g m). I've considered this approach before and it makes me cringe just looking at it. I also closed #56 because I thought we already reached an agreement on this.

The way I see this Tok addition just moves the s from one place to another without solving any particular problem. I am sorry if I sound like a broken record, but what does this PR solve for us that we cannot already do.

Also, now that there is a sample implementation that solves this hypothetical problem. Is there a concrete example which can show the problem and the way it is being solved, that was not possible before?

Unlike previous attempt it does maintain injectivity and allows to work with ST monad without any problems.

I am really against the suggested approach in this PR, but I did fancy your idea of flipping Frozen, so I thought I'd try it out and see what it could bring us to the table.

Also I think it would be desirable to flip Frozen data family.

I know for sure it will not "allow to generalize runPrimGenST & Co", because we have a dependency between generator and the monad in MonadRandom. Nevertheless I thought it was a pretty interesting idea, so I did experiment with it in #72. Let me know what you think and if it is in fact what you had in mind when you suggested it.

@Shimuuar
Copy link
Author

Shimuuar commented Apr 6, 2020

Looks like there's no satisfactory solution for this particular problem at all.

Closing.

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.

2 participants