Does `Cost` need to be `Int`?

[cdsmith]

In experimenting with this library, I've found it very limiting that cost functions must return Int. I often find that I want to keep track of various different contributing factors to the cost, which combine in different ways (sometimes additively, sometimes multiplicatively, etc.). Ideally, equalitySaturation would be polymorphic over the choice of cost type, with only an Ord constraint. If that's not possible, then at the very least, Integer instead of Int would free me from concern about overflowing Int when I'm trying to work around the issue.

[alt-romes]

Hello @cdsmith,

Thanks for pointing this out. No! There's no reason for it to be Int. I've already submitted a patch that makes CostFunction polymorphic over Cost (with the Ord constraint) in #11

This usability feedback is invaluable to improving the package since I couldn't think of nearly enough use cases on my own.

Do submit issues on any other things you come across and believe could have a better abstraction or behavior.

Thank you kindly

[alt-romes]

@cdsmith I've released version v0.2.0 where these changes are now live: https://hackage.haskell.org/package/hegg-0.2.0.0/docs/Data-Equality-Extraction.html#t:CostFunction

Thanks!

[cdsmith]

Thanks!