| 04:11 | <sffc> | Hi, everyone! Thanks Chris for making this room! I've been in a lot of DMs and other different communication channels with different subsets of people regarding the Decimal and Measure proposals, so I thought we would benefit from a single forum to talk and plan. |
| 04:13 | <sffc> | I had a good conversation with nicolo-ribaudo after the session I hosted in the December plenary. Basically, I would really like to see these proposals advance together as soon as possible. It might not seem like it, but I feel we are the closest we've been to getting a proposal that everyone on the committee is happy about. |
| 04:14 | <sffc> | It looks from the outside that we've been going in circles, but I describe it more as a helix: when we go back to the shape of a proposal we've had before, we arrive there with more stakeholders and a much more foolproof specification and understanding of the problem space. |
| 09:25 | <Jesse> | thanks for setting up this room! I think it makes sense to have a common place to discuss |
| 09:26 | <Jesse> | I also agree that what appears to be circular motion is actually progress |
| 09:27 | <Jesse> | having measure & decimal move together makes a lot of sense |
| 09:31 | <Jesse> | we'll be presenting a vision in February that unifies all these threads |
| 12:13 | <eemeli> | For Measure, this may also be relevant: https://github.com/mozilla/explainers/blob/main/amount.md That document also links to some relevant prior art & previous discussions. |
| 18:57 | <littledan> | I'm very happy to hear about this progress, and excited to learn more |
| 18:59 | <sffc> | we'll be presenting a vision in February that unifies all these threads |
| 19:00 | <littledan> | sffc: When you say that you imagine Decimal and Measure advancing together, which version of Decimal do you have in your head? |
| 19:13 | <sffc> | I'd like to see something based on the "bonus slide" in my November presentation. Basically a form of hybrid solution. I expect lots of bikeshedding to follow |
| 19:26 | <littledan> | great, so, like, which one? |
| 19:27 | <littledan> | this? https://docs.google.com/presentation/d/1Uzrf-IwPrljF2BhCbCWuwQxlgGSm_bcd3FRbPO3Yrio/edit#slide=id.g31a6e89a509_0_8 |
| 19:28 | <littledan> | do you want to propose two decimal types (with and without quanta)? |
| 19:39 | <littledan> | bikeshedding is good. I'm curious what you'd change vs the current proposal (besides advancing Measure) |
| 19:43 | <eemeli> | My preference would be to encapsulate within Measure the protocol that we need for interacting with Intl.NumberFormat, including formatting precision as fraction or significant digits, so that Decimal only needs to hold a numerical value. |
| 19:44 | <littledan> | I think I agree with that, but I imagine you'd still be able to pass in a Decimal directly (just like you can pass in Numbers) |
| 19:48 | <eemeli> | Sure, but if you're coming from some other decimal representation (say, one used by a JS library) that might incorporate precision with the value, a Measure would allow you to represent the value as a numerical string + give the precision separately. |
| 19:48 | <littledan> | sgtm |
| 20:29 | <sffc> | I don't completely agree with Eemeli's position |
| 20:32 | <sffc> | What I'd like to avoid is a Decimal proposal that doesn't consider Intl's needs and a separate Measure proposal that doesn't consider 262's needs |
| 20:55 | <littledan> | can you elaborate on that? what is it that you don't like? If we verify that the decomposition is clean, correct and logical, that is a way of considering the other's needs. |
| 21:31 | <sffc> | If TC39 were to bless a Decimal-without-precision as the recommended number type, the well-known Intl bug will continue to exist indefinitely. ECMA-262 numbers should "just work" when interoperating with Intl |
| 21:33 | <sffc> | That's what I mean about "avoid a Decimal proposal that doesn't consider Intl's needs" |
| 21:34 | <sffc> | In the other direction, I would like to see Measure become a standard protocol for interacting with dimensioned values (units and currencies). A software program already written using Measure can then easily change toString to toLocaleString and it will just work. |
| 21:36 | <sffc> | A potential three-layered solution could be workable: one with NormalizedDecimal128, FullDecimal128, and DimensionedDecimal128. Intl can accept the later two. |
| 22:00 | <eemeli> | I'm actually not quite sure what "the well-known Intl bug" is in this context. Could you elaborate a bit? |
| 22:08 | <nicolo-ribaudo> | It's about how you need to make sure to pass the same formatting option to separate APIs so that their results are coherent (NumberFormat and PluralRules), because the number that you pass to them doesn't encode all the necessary info |
| 22:25 | <littledan> | this feels a lot like the ISO calendar debate |
| 22:26 | <littledan> | I'm not really convinced that when we run into a problem, we need to make it a really noisy part of the API. I think it's enough to ensure that we have a data type that supports the right operations (here, Measure) |
| 22:27 | <littledan> | (sometimes it feels like pluralrules should've been a method on NumberFormat instead of a separate class) |
| 22:27 | <sffc> | I think in Temporal we ended up with the right data model, and we worked out a way to make it not be too "noisy" |
| 22:28 | <littledan> | well, I don't want to relitigate that, but in that case we did end up with only now methods for the ISO calendar, while making sure that we had a data model that worked with all calendars. Having just normalized decimal + Measure + NumberFormat forces you to explicitly construct a Measure instance might be analogous. |
| 22:28 | <littledan> | I don't feel extremely strongly about the ergonomics of Decimal + NumberFormat; I'm OK if you need to explicitly wrap it with something that gives it precision |
| 22:31 | <sffc> | I think that's basically the three-layered solution but without the middle layer |
| 22:32 | <sffc> | myNormalizedDecimal.withFractionDigits(3).toLocaleString("th") |
| 22:33 | <littledan> | Yeah, I'd be happy with that. What do you think? |
| 22:37 | <sffc> | Overall I'm happy with this composable data model. Ideally with the middle layer, and with names that need to be bikeshed. |
| 22:38 | <littledan> | can you explain the importance of the middle layer? |
| 22:38 | <littledan> | I'm not really sure when someone would want to use it |
| 22:39 | <sffc> | In this model, a FullDecimal128 is a DimensionedDecimal128 without a dimension. It is what feeds Intl APIs. |
| 22:40 | <sffc> | It could alternatively be modeled as a DimensionedDecimal128 with a null unit. But if we have the opportunity, it seems having a self-contained FullDecimal128 is a better design. |
| 22:40 | <sffc> | It allows things like (2.5m).withFractionalDigits(2).withCurrency("USD").toLocaleString("en-CA") |
| 22:43 | <littledan> | yeah, I guess it's analogous to how, in Temporal, we avoided data types with null things |
| 22:43 | <littledan> | agree that this should work |
| 22:44 | <littledan> | this could be done in a "weakly typed" way (with null units) or in a strongly typed way (with the mid layer) |
| 22:44 | <sffc> | We could make NormalizedDecimal128.prototype.withFractionalDigits return a DimensionedDecimal128 with null unit, and DimensionedDecimal128.prototype.withCurrency throws an exception if the unit is not null. But that seems not as clean as a different object in the middle with its own methods. |
| 22:44 | <littledan> | why would it be DimensionedDecimal128 and not DimensionedNumeric (so it works with Number too)? |
| 22:45 | <littledan> | yeah, I think we share an understanding of the design space and can consider the difference to be "bikeshedding" (though at a high level) |
| 22:47 | <sffc> | why would it be DimensionedDecimal128 and not DimensionedNumeric (so it works with Number too)?
|
| 23:27 | <littledan> | when you say "how precision should work", are you imagining implementing arithmetic operations or anything like that on these? |
| 23:27 | <littledan> | or comparisons, etc |
| 23:30 | <sffc> | What I mean is more like, let's avoid a debate about whether precision should be represented as fractionDigits, min/max FractionDigits, significantDigits, errorBar, etc. Like, I think it's not valuable and potentially harmful for there to be a difference between (2.5m).withFractionDigits(2) and (2.5m).withSignificantDigits(3). But this isn't a topic we've discussed very much and I haven't heard many arguments one way or another. |
| 23:31 | <littledan> | oh, I see. I think once we decide we're working in terms of base-10 quanta, we sort of have an answer which can apply to Numbers as well. But I'm not sure if this answer serves the needs of these i18n applications. |
| 23:35 | <littledan> | anyway we could put that answer in Measure |
| 23:38 | <littledan> | but probably an API shouldn't be in terms of quanta; probably it should just be fractionDigits... |
| 23:38 | <littledan> | we can make sure that the data model acts the same as if it were stored in terms of quanta (I think that would be the case "for free") |
| 23:40 | <littledan> | quanta could probably give us a well-defined data model that we could derive from fraction digits, significant digits, etc. I agree that those differences should disappear in the measured value. |