santiweight
commented
2 years ago Oh one issue that I would have with the current state of the library is the following:
a library based on "poker" will almost always have their own "Game" type. In particular, your type is for one view (a very valid view) of a game's state. But I think keeping such states would be better. Otherwise users will have to qualify imports whenever calling import Poker or hide imports, both of which are very much not ideal.
ghais
Heya! It turns out I am also releasing a poker library imminently. I was actually planning on using the name "poker" but I see you've taken that recently. I'm fine with not owning "poker"! and I think what I'll do is do a PR to add types that I have locally.
The thing I wanted to contest was what the "poker" library should contain, or at least get your thoughts on it.
I would personally argue for the poker library to contain only types. Then the monte carlo stuff would be in a poker-monte library. I think this would be a good way to structure the library in order to have a modular basis that all poker libraries can grow off. The more in the base library - the more fracturing.
However, I don't think this is a huge priority. I'm happy to get on a phone call etc to discuss - since there's only a couple (around 4 including you and I) poker Haskellers. So getting on the same page would be great!
Just to give some info, I have three packages: