Revisiting Decimal (was: Prioritized list of Decimal method additions)

Sam Ruby rubys at
Wed Dec 3 17:53:05 PST 2008

Brendan Eich wrote:
> On Dec 3, 2008, at 1:04 PM, Sam Ruby wrote:
>> I saw the meeting minutes, and got a debrief from Allen yesterday.
>> I'm still unclear on how to proceed with Decimal, even if the new
>> target is Harmony.
>> Waldemar's issues were raised and responded to prior to Kona:
> Did this address Waldemar's other message?

The "no user visible cohorts" addressed that particular concern.

> I also don't see a reply to David-Sarah Hopwood's message:

Given that the spec text has been removed, the way I would like to 
proceed is to first come to an agreement on the semantics we desire, and 
for that I would like to solicit comments on the output produced by the 
implementation I produced.

While I agree that Decimal wrappers are useless; but I think that 
consistency argues that they need to be there (in fact, I was talked 
into putting them there); again I refer back to the output produced and 
solicit comments.

>> What are we left with relative to the the following output from the
>> code that I wrote?
> Looks like we may need Waldemar to comment or elaborate on his last post 
> (first link above).
>> Relative to that output, I've heard two issues.
>> The first was "no user visible cohorts".  The issue is Waldemar's
>> insistence that ES is irretrievably broken if array lookup for
>> x[1.10m] respects the trailing zero.  IIRC, Brendan's position was a
>> more pragmatic one, namely that "small" integers (like, say, up to
>> 10**20th) are the only values for which toString must avoid both
>> exponential notation and trailing zeros, other values shouldn't get in
>> the way of "doing the right thing".  That would have been fine, but
>> unfortunately he couldn't make the meeting (something I definitely
>> understand).  Mike and I weren't then, and still aren't happy about
>> conceding to Waldemar's position on this one, but at Redmond we did
>> with the understanding that with that concession, Decimal was "in".
> This Redmond-meeting result did sound like a breakthrough in any event. 
> Was it memorialized with spec changes?

There were spec changes that went in as a result of the Redmond meeting, 
yes.  At least one was identified before the Kona meeting by Waldemar 
(and fessed up to by me) as having been botched by myself (and => or).

>> The second was the duplication between "Math.min" and "Decimal.min".
>> I was operating under the "if it ain't broken, don't fix it"
>> guidelines.  To date, Math.min *always* returns a Number, never an
>> Object.  Waldemar apparently feels that people will call the wrong
>> function.  To me, this is a "you say N-EEE-THER, I say N-EYE-THER"
>> issue.  If the consensus is that Math.min should be changed and
>> Decimal.min should be removed, that's a pretty quick fix.
> This doesn't seem like a big problem, by itself.

Agreed, and in any case, one that I would eagerly adopt.

>> So now the question is: where are we now?
> The two general kinds of problems from the Kona meeting were:
> 1. Spec bugs, not just typos but material ones that couldn't be fixed by 
> that meeting, which was the deadline for major additions to ES3.1 not 
> already in the spec.

For the moment, I would like to split that list into two categories: 
areas where there isn't yet agreement within the committee on how to 
proceed, and the best way I know how to make progress on that is to come 
to agreement on the behavior desired, hence my suggestion that we look 
at concrete test cases; and a list of places where I erred in my 
converting my understanding into prose.

No matter how we proceed, the first list needs to be captured and 
addressed eventually anyway.

> 2. Future-proofing arguments including: do we need Decimal wrappers for 
> decimal primitives. I know we've been over this before, but it still is 
> an open issue in TC39.

That does sound like the type of issue that I would like to see us 
identify and work to resolve.  Two questions come to mind: (1) can 
anybody identify a specific expression which behaves differently that 
one would desire, and (2) if we've been over this before, what does it 
take to actually close this issue this time for good?

> I'd appreciate Waldemar's comments; and those of other TC39ers too, of 
> course.
> /be

- Sam Ruby

More information about the Es-discuss mailing list