Policy on Show instances

[dmcclean]

I recently learned that Show instances are supposed to generate valid Haskell code.

Ours doesn't, it just does human-readable pretty printing.

We could probably change it so that show (36 :: Double *~ inch) was something like 0.9144 *~ meter (with appropriate precedence) instead of 0.9144 m, is this desirable?

Relatedly, are we OK with overlapping show instances if we can prove that they give the same behavior in the overlapping case? This would be a boon to the fixed-point branch:

instance (KnownDimension d, Show a, Fractional a) => Show (Quantity d a) where
  -- we just show the value and add the unit, we know the scale factor is one

instance (KnownDimension d, KnownExactPi s, Show a, Real a) => Show (SQuantity s d a) where
  -- explained below

In the latter instance, we do the same thing as the first one if the scale factor isExactOne (thus guaranteeing the same behavior in the overlapping cases). If the scale factor is other than one, we convert something like (Quantity 372) :: SQuantity (1 / 10) DLength Int16 to something like "Quantity 372 {- 37.2 m -}" which (a) is valid Haskell, (b) round-trips the value, and (c) gives you some kind of clue to the meaning when you are in GHCi, which can get confusing with more complicated scale factors.

[dmcclean]

I may have a sneaky way to unify these instances, by using another closed type family in exact-pi.

[dmcclean]

So without overlapping anything:

instance (KnownDimension d, E.KnownExactPi s, Show a, Real a) => Show (SQuantity s d a) where
  show (Quantity x) | isExactOne s' = show x ++ showName n
                    | otherwise = "Quantity " ++ show x ++ " {- " ++ show q ++ " -}"
    where
      s' = E.exactPiVal (Proxy :: Proxy s)
      s'' = approximateValue s' :: Double
      q = Quantity (realToFrac x P.* s'') :: Quantity d Double
      (Unit n _ _) = siUnit :: Unit 'NonMetric d a

We swapped the Fractional context that's presently required (kilogram strikes again) for a Real instance instead, except for churn I think it's a good trade. The KnownExactPi constraint is free in the sense that every type in the kind has one.

Example results (newlines added for clarity on github):

> let (m,n) = parseAis "!AIVDM,1,1,,B,25Cjtd0Oj;Jp7ilG7=UkKBoB0<06,0*60"
> runBitGet m getMessage
Right (ClassAPositionReport {messageType = MAssignedScheduledClassAPositionReport,
repeatIndicator = 0,
userID = MMSI 356302000,
navigationalStatus = NavUnderWayEngine,
rateOfTurn = RateStarboardNoSensor,
speedOverGround = SpeedSpecified Quantity 139 {- 7.150777777777778 m s^-1 -},
positionAccuracy = False,
longitude = Just Quantity -42975686 {- -1.2501120316720529 -},
latitude = Just Quantity 24235415 {- 0.7049796455620359 -},
courseOverGround = Just Quantity 877 {- 1.530653753999027 -},
trueHeading = Just Quantity 91 {- 1.5882496193148399 -},
timeStamp = Just 41,
positionFixingStatus = PosStatusNormal,
manueverIndicator = 0,
raimFlag = False,
communicationsState = SOTDMA {syncState = SyncUtcDirect, slotTimeout = 3, submessage = ReceivedStations 6}
})

Note that we could still benefit from participating in the whole showsPrec game once I figure out how to do so, so that we'd get SpeedSpecified (Quantity 139 {- 7.150777777777778 m s^-1 -}) instead of SpeedSpecified Quantity 139 {- 7.150777777777778 m s^-1 -}.

[bjornbm]

This is something I have thought about in the past. My impression was that it is not a type class law that the show instance should generate valid haskell code, even if it is convenient. But maybe the Haskell community has evolved in that direction?

There is another possible, less stringent property: that read . show is equivalent to id (given adequate type information). We don't have a Read instance right now so it is somewhat beside the point perhaps.

In the end (in 2006) I decided that readability and terseness was more useful to me (using ghci as a glorified calculator) and went with the current 'show'. But we could change it if you think it is better to produce valid code.

If we go that route we really need to get the parentheses working, otherwise it seems meaningless since SpeedSpecified Quantity 139 {- 7.150777777777778 m s^-1 -} will not type check anyway.

I also wonder how useful the valid haskell code is without type signatures in our case? I mean; what can you do with SpeedSpecified (Quantity 139)??

Should we export a function equivalent to Quantity to not leak the constructor (or use *~ siUnit or something)?

[dmcclean]

Good questions.

Its useful only in a context where the result type is already determined. For me that usually means some large record like the one above.

Getting the parentheses working is confusing but not ultimately that difficult. Basically it's just about figuring out what precedence level to pass to showParen from showsPrec and rewriting into shows-style accumulating form.

I'm pretty much OK with using the constructor directly, because nobody seems to agree on what imports you have to have in scope to use it as code, and so anyone who wants to use it that way can import the Coercion module?

I'm ambivalent on this one. The terse form is good for me too for GHCi-as-a-calculator. The real thing I want is to figure out some way for the fixed-point Show instance to coexist with the ordinary Show instance, and this seemed like the best I could come up with.