On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
On Thu, 3 Jun 2021, Travis Cardwell wrote:
The Render and Parse type classes in Data.TTC have no instances, allowing developers to write their own instances for Int for example, but some default instances can optionally be imported from Data.TTC.Instances when they are appropriate.
Are these instances orphan?
Indeed they are. I use the following directive to hide the warnings for that module: {-# OPTIONS_GHC -fno-warn-orphans #-}
The common way to get around the one-instance-per-type limitation is to use newtypes. I generally do not use this strategy with TTC to provide different ways to format text, however.
Is it feasible to have a newtype for any of "%3d", "%03d", "%05d" ...?
In cases where the formats are fixed and finite/few, one could create a newtype corresponding to each format. Personally, I think that using a formatting function would result in a better design in most cases, however. For example, one might want to format numbers according to locale, using appropriate decimal separators. If newtypes are defined for each supported format, the constructor could be passed to functions to determine how values are formatted. formatQuantityList :: TTC.Render a => (Quantity -> a) -> [Quantity] -> TLB.Builder In my opinion, passing a formatting function instead results in a better design because it is more flexible. formatQuantityList :: (Quantity -> TLB.Builder) -> [Quantity] -> TLB.Builder This function might be called as follows, where locale is a sum type that enumerates the supported locales (instead of using newtypes) and the formatFor function formats the Quantity value appropriately for the specified locale: formatQuantityList (Quantity.formatFor locale) quantities I hope that I understood your question correctly and that my response is helpful. Best regards, Travis