search

tonyday567 / poker-fold

Other
2 stars 0 forks source link

Include specialised versions of Poker.Range in poker-base #2

Open santiweight opened 2 years ago

santiweight commented 2 years ago

ShapedHandRange. We can definitely accommodate this in poker-base. This might also be a good opportunity to use newtype ShapedHand = ShapedHand Word8 for ShapedHand since I think with pattern synonyms we can hide this implementation detail...

newtype ShapedHandS = ShapedHandS {unShapedHandS :: Word8}

newtype RangedHand a = RangedHand
  { array :: Array '[169] a
  }

The rest of the functions in ShapedHandRange seem very reasonable and easy to add to poker-base.

Design question - should we use data/type families for this? I think we should just leave it for now and include a super-pretty API if we really need to... (We have agreed this in private also I believe)

I couldn't find any other specialised Ranges yet - let me know if I missed one!

tonyday567 commented 2 years ago

Yes, RangedHand is the only specialisation there. An issue is that Array picks up a dependency on numhask-array which comes with some complexity. I just love using the representable methods - tabulate and index makes so much sense once you get used to them and create compact clear code, but it isn't standard by any stretch, so it might cause confusion for others.

santiweight commented 2 years ago

I don't know anything about numhask-array, but I think (as you are alluding to in your comment) that we should keep away from a non-core-library dependency. I think it will cause everyone more trouble than it's worth :(

Do you have any sense of whether using vector et al will have a big reduction in speed/usability vs numhask-array? It would be good to try to reach parity in those regards even if we can't use numhask-array...

tonyday567 commented 2 years ago

To get a Representable instance of anything, you need a fixed size at the type level - can't do it with a list or a vector. If you go with just a vector (or a list), then you are pretty much signing up to a lack of safety about vector size; writing guards everywhere or leaving open the possibility of segfaults due to bad indexing.

IF representable is the right way to go for poker-base, probably the best solution would be to copy the Array type from numhask-array - underneath is a boxed vector. I'm not using the associated functions anywhere yet - just the size wrapping and the Representable instance.