♻️ Consider re-organising things.

[hayleigh-dot-dev]

The way the code is organised at the moment, it becomes impossible to use some modules alongside the same-named ones in the stdlib without some aliasing. It seems quite reasonable to want to import both gleam/int and gleam_community/maths/int and having to alias one is quite clunky.

I'd much prefer to see things organised by domain/use than type, for example a gleam_community/maths/trigonometry module: trigonometry.asin feels a lot more appropriate to me than float.asin.

For functions that are defined both ints and floats, like sign I'd rather see those functions live in the same place with some established naming convention like int_sign and float_sign, or sign and signf, or whatever...

For the list_ modules consider whether the API can be simplified by simply asking consumers to provide implementations of some behaviour, instead of int_list.maximum([...]) and float_list.maximum([...]) this could be unified maths.maximum and the user can provide int.compare, float.compare, or float.loosely_compare as they see fit.

---

I'd consider the requirement to alias imports to use the package a significant blocker for an otherwise very useful package, but I'm not familiar enough with the domain to provide specific suggestions for re-organising things. Hopefully this is enough to point you in the right direction ❤️