Philosophy: Arithmetic strategy for `Bounded` types

Sorry for asking a philosophy question on here, but PureScript is the most principled language that I’ve worked with, and is the only language that I’ve had to wrestle with some of these principles. My confusion comes from comparing how one works with Date s and how one works with Int s - both of which are Bounded and Enum . Both types allow for basic arithmetic operations, but the strategy differs quite a bit. It seems like the strategy for Int is to make sure your program is working with Int s that fall pretty conservatively within the bounds of Int , and get undefined behavior if you start pushing those bounds, but the strategy for Date is that any arithmetic operation returns a Maybe to account for a possible overflow of the bounds. In my experience, it seems that you’re honestly more likely to be working with Int s that overflow than you are to be working with Date s that overflow, though perhaps that’s not relevant. I guess my question is:

  1. would it be preferable that the Int type behaved more like Date for arithmetic (where all arithmetic returns a Maybe in case of overflow), or
  2. would it be preferable that the Date type behaved more like Int for arithmetic (assume arithmetic works without overflow and the programmer is responsible for making sure their program works with “sensible” values), or
  3. is there a reason why Date and Int arithmetic differ in some way such that both approaches are correct for their own context?

My motivation is that I’m often wishing that Date worked more like Int (I’m sure my application only ever handles dates between years 1900 and 2100), but I’m always worried that I’m missing something. Maybe I should just be writing my own version of adjust that handles overflows the same way that + does, but perhaps there’s a reason it’s not natively implemented that way?

Thanks!

5 Likes