export means "trouble" in my dialect of Scala

[benhutchison]

I've hit several errors in the last couple of weeks which have hinted at problems introduced by exporting types, but Ive finally found a clear-cut example.

It concerns Second which is originally defined in the coulomb.units.si package. It's exported by time within coulomb, but I'm similarly exporting it in my basetypes package:

export coulomb.units.time.{*, given}
export coulomb.units.si.{Second as _, ctx_unit_Second as _, *, given}

The problem seems to happen because the intersection of two factors: it seems like an exported type isn't a transparent alias to the original, but a brand new type, And yet somehow, the original Second type gets "captured" somewhere within Coulomb's machinery.

The result is visible below. It is not possible to subtract seconds from milliseconds, because coulomb doesn't recognise that they're derived from the same Second substrate type.

The line that fails to compile is noisy because I've ascribed explicit types to make it clear coulomb.units.si.Second doesn't appear anywhere.

[error] 88 |    val existingOrderTimes = (tradePointTimestampMs: EpochTime[Long, basetypes.Milli * basetypes.Second]) - (timeUnit.interval: Quantity[Long, basetypes.Second])
[error]    |                                                                                                                                                                ^
[error]    |Subtraction not defined in scope for DeltaQuantity[Long, basetypes.Milli * basetypes.Second] and Quantity[Long, coulomb.units.si.Second].
[error]    |I found:
[error]    |
[error]    |    basetypes.ctx_deltasubq_1V2U[coulomb.units.si.Second, Long,
[error]    |      (basetypes.Milli * basetypes.Second)
[error]    |    , Long, coulomb.units.si.Second](<:<.refl[Long], scala.util.NotGiven.value,
[error]    |      basetypes.ctx_Quantity_Conversion_2V2U[Long, coulomb.units.si.Second, Long,
[error]    |        (basetypes.Milli * basetypes.Second)
[error]    |      ](basetypes.ctx_VC_Long[Long](scala.math.Numeric.LongIsIntegral),
[error]    |        /* missing */
[error]    |          summon[
[error]    |            coulomb.conversion.UnitConversion[Long, coulomb.units.si.Second,
[error]    |              basetypes.Milli
[error]    |             * basetypes.Second]
[error]    |          ]
[error]    |      )
[error]    |    , ???)
[error]    |
[error]    |But no implicit values were found that match type coulomb.conversion.UnitConversion[Long, coulomb.units.si.Second, basetypes.Milli
[error]    |
[error]    |* basetypes.Second].
[error]    |
[error]    |One of the following imports might make progress towards fixing the problem:
[error]    |
[error]    |  import basetypes.coulombsupport.ctx_deltasubq_1V1U
[error]    |  import basetypes.coulombsupport.ctx_deltasubq_1V2U
[error]    |  import basetypes.coulombsupport.ctx_deltasubq_2V1U
[error]    |  import basetypes.coulombsupport.ctx_deltasubq_2V2U
[error]    |  import coulomb.ops.standard.all.ctx_deltasubq_1V1U
[error]    |  import coulomb.ops.standard.all.ctx_deltasubq_1V2U
[error]    |  import coulomb.ops.standard.all.ctx_deltasubq_2V1U
[error]    |  import coulomb.ops.standard.all.ctx_deltasubq_2V2U
[error]    |  import coulomb.ops.standard.deltasubq.ctx_deltasubq_1V1U
[error]    |  import coulomb.ops.standard.deltasubq.ctx_deltasubq_1V2U
[error]    |

[erikerlandson]

I have also run into some hard (for me) to understand corner cases where export does not behave the way I expected. My attempts to understand what's happening and why frequently left me confused and frustrated, and in some ways it all feels a bit brittle, like it all barely allows me to do what I'm doing.

In case it helps, here are some issues I've filed against scala 3 while trying to write scala3-coulomb

• export object.given does not respect priorities scala/scala3#15264
• export interacting weirdly with scala.Conversion scala/scala3#12700
• extension method involving opaque type fails scala/scala3#15255
• Opaque type's type parameter widened causing implicit lookup failure scala/scala3#12950
• unexplained "ambiguous implicit arguments" error scala/scala3#14585

[benhutchison]

Hi Erik,

First up, thanks for sharing your issues list. Wow! You clearly are one of the pioneers pushing the bounds of what Scala 3 can do 👏

I might well be catching up, but I had a bit of an "aha" moment this morning. I realized that my earlier statement "it seems like an exported type isn't a transparent alias to the original" isn't how exports were intended to work. They are supposed to be transparent aliases, and oftentimes they do work.

Here's an example I fashioned with a "diamond" dependency structure, showing that Scala3 can reconcile exported and imported views onto the same type:

object Library:
  case class LibClass()
  
object BaseExports:
  export Library.LibClass
  
object AppComponent1:
  import Library.*
  
  def useLibClass(l: LibClass): Unit = ???
  
object AppComponent2:
  import BaseExports.*

  AppComponent1.useLibClass(LibClass())

So I now suspect the compiler error I hit above in Coulomb (Subtraction not defined in scope for DeltaQuantity[Long, basetypes.Milli * basetypes.Second] and Quantity[Long, coulomb.units.si.Second]) is a compiler bug where in some cases it gets confused by the exported alias.

Nxt step is to test that hypothesis by reverting to purely importing coulomb without my basetypes layer. That's actually non trivial as my app code is rather dependent on my basetypes definitions.

[erikerlandson]

a compiler bug where in some cases it gets confused by the exported alias.

I believe I have seen similar bug with the exported EpochTime and Temperature aliases, for example it was getting confused by Second and whether it was from si or exported via time. As you say, I think it's supposed to treat them as aliases.

I'm not 100% certain if it is a scala type system bug or possibly some bug with failing to use dealias down in my metaprogramming.

[benhutchison]

failing to use dealias down in my metaprogramming <- sounds plausible. If I can help formulate test cases to smoke out any issues in coulomb please let me know.

[benhutchison]

OK, pulling on this dealias thread a bit...

Observed behavior in above example is that, by the time we've reached ctx_deltasubq_1V2U(ql: DeltaQuantity[VL, UL, B], qr: Quantity[VR, UR]):

• UL has not been de-aliased, ie DeltaQuantity[Long, basetypes.Milli * basetypes.Second]
• UR has been de-aliased, ie Quantity[Long, coulomb.units.si.Second]

My question to you Erik is, which is intended? Should the units going into a delta subtraction be dealiased, or not?

I think the answer is surely "yes". De-aliasing through exports is essential to recognize different exports of the same underlying units, to see that they are the same and thus compatible types.

So I think the problem sits with DeltaQuantity[Long, basetypes.Milli * basetypes.Second], these units ought to be dealiased to the si package.

WDYT?

[benhutchison]

Actually, as I discovered in #410 the different type aliases in the error msg is probably a red herring, real issue is just that cannot subtract seconds from millis without first aligning types.