Revisiting Decimal (was: Prioritized list of Decimal method additions)
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:
esdiscuss/2008-November 008074.html
Did this address Waldemar's other message?
esdiscuss/2008-September/007631
I also don't see a reply to David-Sarah Hopwood's message:
esdiscuss/2008-November/008078
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?
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.
So now the question is: where are we now?
The two general kinds of problems from the Kona meeting were:
-
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. -
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.
I'd appreciate Waldemar's comments; and those of other TC39ers too, of
course.
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:
- 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.
- 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
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:
esdiscuss/2008-November/008074
Quick summary: there are at least eight sections with typos and transcription errors. By transcription errors, I mean places where the prose doesn't match the output of the code that I posted previously. Those are embarrassing, but at this point moot. Pratap has already excised Decimal from the spec.
What are we left with relative to the the following output from the code that I wrote?
intertwingly.net/stories/2008/09/20/estest.html
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".
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.
So now the question is: where are we now?