Two questions arising from trying to support java.math.BigDecimal in Coulomb

[benhutchison]

Hi @erikerlandson

I haven't been in touch recently but my grand experiment with Coulomb continues. It's well and truly integrated into a financial application and, after paying the initial learning curve and establishing some infrastructure, has "just worked", providing the expected "value" in terms of increased type safety around managing distinct quantities.

ATM I'm using Coulomb core and spire, including Delta units, but haven't used the other modules yet. The emerging collections module looks interesting, as I have found myself defining custom methods on eg Iterable[Quantity[BigDecimal, Asset]] like qSum and qSizeMeanVariance that compute stats over quantities.

Anyway, I'm at a point where I want to support a new type of value V: for reasons, I need to support java.math.BigDecimal, as distinct from its Scala cousin.

The docs around support for new Value and Unit types are excellent and quite lucid, but I do have a couple of questions..

1. The [Wrapper[T] example code for UnitConversion is written in terms of an underlying UnitConversion[T] that's assumed to pre-exist. In my case, I want to define a UnitConversion[java.math.BigDecimal, U1, U2].

   One way I thought of would be to use the UnitConversion for Scala's BigDecimal, and briefly wrap-up java decimals into scala decimals during conversion. This all happens at compile time anyway right..?

   But I was wondering if you would advise another approach..?

2. More conceptually, I was wondering how to use/extend ValuePromotionPolicy in a modular way. Ideally. By which I mean, not requiring a singleton total "god" VPP in each app, but being able to extend an existing VPP incrementally in the module that adds support for java.math.BigDecimal. Do you consider this feasible?

   I wanted to avoid the need for each library or module that adds support for new value types to redeclare its own "one true VPP". It would be nice if multiple modules could coexist without prior arrangement (otherwise we might as well all use Haskell 😛 ).

[benhutchison]

OK, made flowing progress today, and can attempt answers to my own questions. Coulomb was a pleasure to use :)

re 1: It seems like unit conversions just work for a new value type, without writing any implicit UnitConversion code! I now have a working unit test which is computing units for java.math.BigDecimal and I never wrote anything specific for unit conversion. :nice:

re 2: ValuePromotionPolicy does want a type-level list defining the value promotion ordering across the whole universe in one place. However, by "unbundling" the exports in the standard policy, I could provide all the value conversion implicits for java.math.BigDecimal in a module, but leave the final ValuePromotionPolicy unspecified. I provided it later, in the application code, when all the constituent value types are known. So this at least is a way to defer it until the full, closed set is known.

[benhutchison]

Erik, have you ever hit something like this compiler error with Coulomb?

Happened in a unit test, when comparing incompatible/nonsensical quantities for equality.

[error] java.lang.AssertionError: assertion failed
[error] scala.runtime.Scala3RunTime$.assertFailed(Scala3RunTime.scala:11)
[error] dotty.tools.dotc.core.TypeOps$.dominators$1(TypeOps.scala:249)
[error] dotty.tools.dotc.core.TypeOps$.approximateOr$1(TypeOps.scala:383)
...

TypeOps 249:
assert(ctx.erasedTypes || ctx.reporter.errorsReported)

[erikerlandson]

I don't recognize that compiler error. Were you using === or == ?

Regarding value promotions, one option is to just not define it. It mostly means that mixing numeric types in an expression may not work. In #537, I am planning to remove them altogether, which means that either you need to use q.toValue or enable implicit conversions with scala.Conversion - the effect will be that the value type is always converted to the left-hand argument.

But yes, if you want to add a new numeric type into the value promotion system, you need to define your own ValuePromotionPolicy and create your own custom import policies. Adding ValueConversion or UnitConversion is more modular. Coulomb will use them if it can find them in context.

[erikerlandson]

@benhutchison I think this type assertion compiler crash might be related to some lazy idioms I've got where I'm applying extractors using @unchecked. An example is here:
https://github.com/erikerlandson/coulomb/blob/scala3/core/src/main/scala/coulomb/rational/rational.scala#L178

I assumed these would result in a compile-time error, but I'm seeing them cause compiler exceptions. I can rewrite them with a proper match statement, it's just a bit less elegant in the code.