17:37
<nicolo-ribaudo>
For today's discussion, let's try to be consistent calling it either Measure or Amount to avoid confusion between those that are not up to date with our discussions
17:37
<littledan>
OK, so which one?
17:38
<nicolo-ribaudo>
I'd go with Measure since it's what it was called before
17:38
<littledan>
alternatively: Eemeli's slide mentions amount as the joint class that does both things; maybe we can reserve it for that usage?
17:45
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
My thinking was to call it โ€œmeasureโ€ throughout, though I can briefly mention that thereโ€™s an alternative. Iโ€™d also ask us to not bukeshed on that
17:58
<littledan>
OK good let's stick with Measure then
17:58
<littledan>
do the slides reflect this consistently?
19:03
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
on it!
19:04
<nicolo-ribaudo>
Concretely, I wonder wether we could get some sort of stage 1.7 on Decimal (e.g. we believe it's ready for 2, but just waiting a bit to figure out how the other part integrates with it), and build basic Measure on top of it separately
19:04
<nicolo-ribaudo>
And then advance them together
19:04
<nicolo-ribaudo>
This would keep them separate, while solving the awkward situation of wanting them to basically depend on each other without knowing what's going to happen to the other half
19:06
<sffc>
A common thread I heard is "stronger parts of the proposal should not carry weaker parts". But, the definition of "weaker" versus "stronger" is not consistent between all delegates.
19:08
<sffc>
In past cycles we've heard a fair amount of skepticism that Decimal is motivated. Today is the first time I've heard similar skepticism that Measure might not be motivated.
19:09
<nicolo-ribaudo>
From experience, the more a proposal becomes "concrete" the more people express their skepticism
19:10
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I think in any siloed discussion of a proopsal, we would have to keep referring to the others and refer to the overall vision
19:10
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
it feels that our stage process approach doesn't really support this; it's a matter of presentation
19:11
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
the module harmony approach seems to be successful
19:11
<sffc>
The ideas are all still a bit abstract. Maybe having a library implement the whole proposal would be helpful to illuminate how it works and fits together.
19:11
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
that sounds like a nice idea
19:32
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
it seems to me that there are a couple options on the table for structuring this:
19:33
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>

I believe Eemeli's idea is:

  1. measure v1 (opaque)
  2. decimal (integrates 1)
  3. measure v2 (exposes decimal)
  4. (maybe) unit conversion
19:33
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
(lmk if I'm getting this wrong)
19:33
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
another approach could be:
19:33
<littledan>
I feel like we've done a good job explaining the motivation for Decimal, and our current challenge is more of building internal consensus on the form that Decimal should take, and then strongly pushing that.
19:34
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
  1. decimal
  2. measure (integrates decimal, adds convert-to-measure functionality to decimal)
  3. unit conversion
19:49
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
with this second approcach, what we're calling "merging" would happen in step 2
19:50
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
my gut sense is that this 3-step approach is less likely to fail on motivation grounds
19:50
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I fear that in the approach where we lead off with an opaque measure, we might fail because it's too thin/unmotivated
19:51
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
like, even if everyone knows that the opaque measure just prepares the ground for a more featureful future, it still needs to advance on its own
21:44
<sffc>

I think eemeli prefers

  1. Measure
  2. Decimal
  3. Unit Conversion
21:45
<eemeli>
Yes.
21:46
<sffc>
I am not too worried about getting alignment from committee on thin, opaque Measure. I believe Dan [Minor] agrees with that direction overall, I can have more internal conversations with Shu, and I didn't hear any other fundamental blocking concerns from plenary.
21:46
<littledan>
I have repeatedly asked Eemeli whether he feels like blocking Decimal, and he has not responded. That is very important information here.
21:47
<littledan>
I definitely do not feel like blocking Measure, personally
21:48
<littledan>
I do not at all mind Measure and Decimal advancing at the same time
21:48
<littledan>
(decimal seems ready; I don't see any reason to delay it further, once we have any cross-cutting issues with Measure/unit conversion worked out)
21:49
<littledan>
if we want to delay it, I want to know why
21:49
<sffc>
A desirable outcome from my point of view would be for us to present Measure/Decimal Harmony for Stage 2 in April. And once that happens, they could proceed to 2.7 at separate paces.
21:49
<littledan>
(beyond working out common issues)
21:49
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
given that decimal is essentially ready, and that we could add the measure-decimal integration pretty straightforwardly in (v1 of) measure, I wonder if, practically speaking, it makes sense to focus on decimal for now
21:50
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
happy to present a harmony in april, too
21:50
<littledan>
well, if Ben and Eemeli and Shane are going to prepare Measure for April, I don't see any reason to discourage that (given that there's nothing needed for decimal itself)
21:52
<sffc>
There was a lot of nitpicking today on Measure semantics, like, what syntax do we use for measures and currencies, etc etc, but nothing fundamental. I'm not sure if those are Stage 2 Blocking concerns, but it's still good to get those questions answered. I agree that Decimal is in the state it wants to be in; all the nitpicking was resolved in correspondence with Waldemar in 2024.
21:52
<littledan>
yes, and most of that will be resolved once we clarify that we're talking about a pretty minimal version of Measure
21:53
<littledan>
do we all agree that unit conversions can be "later" if we make Measure be monomorphic-decimal? This was a point that Eemeli made, that it can't be separated because we might later find out that it must be decimal...
21:54
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I think the greater precision offered by decimal is what we need for conversion
21:55
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
(we heard that it's not out of the question to consider rational, though, but I think this is asking more than we can reasonably supply)
21:55
<eemeli>
My primary interest is to get at least an opaque Amount to advance. My major current concern with Decimal is that both it and the Measure proposal claim to be providing a solution for representing monetary values in JavaScript. I think telling developers that they need to choose from two different solutions for that is a bit bad.
21:55
<sffc>
There's still the unresolved question about whether we have the third type that sits between NormalizedDecimal and Measure. Ideally that question would be resolved as part of Decimal/Measure Harmony but it can technically be added later
21:56
<eemeli>
I think we need a presentation at the next or a near-future meeting explicitly presenting unit conversions, taking up that part of the current Measure proposal.
21:56
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
(we heard that it's not out of the question to consider rational, though, but I think this is asking more than we can reasonably supply)
like, rational offers the possibility of exact cancellation, such as (1/3) * 3 === 1 which we won't get from decimal128)
21:57
<littledan>
How do you think we should investigate that? What if we start out with fewer types, and add the middle one if we see that the need is strong?
21:57
<eemeli>
I would be very surprised to find myself blocking Decimal, btw, even if I were to present arguments against it in committee.
21:58
<littledan>
we have some pretty strong arguments for why we're focusing on decimal rather than rational. We're not trying to solve all the problems in the world. We might just need to tersely restate these in the April presentation.
21:58
<littledan>
(for one, trailing zeroes don't make sense in the rational context)
21:58
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I'm happy to consider a "full decimal" class, though it's a bit of an odd duck because it's almost the same as measure, just with no unit
21:58
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
but it's not out of the question
21:58
<eemeli>
One challenge here is that I'm technically not a Measure champion. I discussed taking that role with Ben just before he went on leave, but that was not documented in writing.
21:59
<littledan>
please don't feel held back by these technicalities. That's not a reason to cast yourself as an outside agitator
21:59
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
it certainly fits in with the logic of following temporal's example and having very clear separation of concerns
21:59
<Richard Gibson>
what is a "full decimal" class?
21:59
<littledan>
I agree that it's not out of the question, but I don't see the motivation sufficiently
22:00
<littledan>
non-canonicalized
22:00
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
"full decimal" is an IEEE 754 Decimal128 value without normalization (so "1.2" would be different from "1.20"). Iow it tracks precision
22:00
<eemeli>
I don't mean that I'd be an outside agitator, but that e.g. accepting a rename to Amount or otherwise advancing the proposal is currently quite difficult.
22:00
<littledan>
we're trying to say canonicalize rather than normalize, right?
22:00
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
right sorry, yes
22:01
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I did that switch a while ago but have slipped into identifying the two terms
22:01
<littledan>
sure, well, I feel like that's less a function of the official champion and more about whether you've persuaded anyone in this group that it's a better name.
22:02
<Richard Gibson>
hrm. For the record, I am very opposed to such a mixture of magnitude and precision. The direction presented in this plenary's item is much better.
22:02
<littledan>
The same goes for your suggestion to make one class rather than two--it's not your official position with respect to being a champion or not, but whether you persuade others here that it's a better idea.
22:03
<littledan>
we're operating by a sort of rough consensus here; Ben isn't acting as a harsh dictator
22:09
<eemeli>

My main concern with "measure" is that it feels inappropriate for currency values, which are explicitly mentioned in the very first sentence of the proposal repo:

Modeling units of measure is useful for any task that involves measurements from the physical world. It can also be useful for other types of measurement; for example, measurements of currency amounts.

The word "amount" is more general and less opinionated, as it does not imply how the value was determined. It's also more natural to consider e.g. an "amount of meters" or an "amount of dollars" compared to a "measure of meters" or a "measure of dollars".

22:11
<eemeli>
It's past midnight here and I've had a really long day, so I'll need to leave further serious discussions until later.
22:12
<littledan>
good night!
22:13
<littledan>
maybe at some future point we should have polls in the group, at least for bikeshedding matters like this
22:13
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I'm happy with "amount"
22:13
<nicolo-ribaudo>
Fyi what we do for modules is that basically we consider the whole group as champion (as in, champions cannot make decision without some sort of agreement/majority in the group), but there is value in not everybody championing everything because then you can volunteer as a stage 2.7 reviewer
22:13
<littledan>
do you have a preference between the two?
22:14
<eemeli>
In general, I would find it difficult to reach a consensus on a proposal without involving any of its champions.
22:14
<littledan>
(I don't feel strongly one way or another)
22:14
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
no preference; tbh I think both are 80% solutions
22:14
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
what tips me one way, perhaps, is the use of currency
22:15
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
otoh using non-currency is also a core goal
22:15
<littledan>
I imagine Ben wouldn't want us to pause developing the proposal while he's gone, but maybe his coworkers know more here
22:15
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
so...I feel terminologically stuck
22:16
<nicolo-ribaudo>
Ben would very much prefer us to make progress without waiting for him
22:16
<eemeli>
I would feel much more comfortable developing the proposal if I or someone else actively participating were explicitly noted as a Measure champion.
22:18
<eemeli>
(now actually signing off, will catch up on the scrollback on my tomorrow)
22:18
<nicolo-ribaudo>
Let's add two between you, jesse, and shane?
22:18
<nicolo-ribaudo>
Bye!
22:22
<sffc>
Originally I had advocated for Rational instead of Decimal. I still think Rational is better for i18n due to decoupling data model from formatting. But I dropped this concern given the very limited prior art for rationals, and since even CLDR doesn't really support it.
22:23
<sffc>
Who is the "official" Igalia substitute for Ben? I would like to work with you to get some spec text written for Measure.
22:24
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
I'm not totally unsympathetic to that; I've done a lot of work with Scheme/Lisp and there, rationals are the data model for exact numbers
22:24
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
but there are some downsides
22:24
<littledan>
sounds like Nic is explicitly saying that Jesse can serve as (co-)substitute in this case
22:24
<nicolo-ribaudo>
(I'll get Romulo to give you an official answer)
23:17
<sffc>
๐Ÿ“ข Please review these slides I threw together for the continuation topic this afternoon: https://docs.google.com/presentation/d/1050DHlNOzcN-8LqJQ_6z8j-LryXgEqOcLfcVzkhJyEk/edit#slide=id.p
23:24
<Chris de Almeida>
sffc: the continuation was scheduled for tomorrow morning to accommodate Eemeli
23:29
<Chris de Almeida>
(also we only have 15 mins available left on paper today)
23:32
<nicolo-ribaudo>
Lgtm โœ…๏ธ
23:33
<nicolo-ribaudo>
One question that is going to come up is "Why no Intl.Amount?"
23:44
<Jesse (TC39 ๐Ÿ‡บ๐Ÿ‡ธ)>
+1 from me