On Aug 23, 2008, at 8:23 PM, Sam Ruby wrote:
The remainder of the quote that was relayed to me was that spec'ing
the operators would not be hard. I took it upon myself to
refamilarize myself with spider monkey and implement these operators,
and despite it being a decade or so since I've done any serious C/C++
coding was able to complete that task in a long weekend.
You know that I'm glad you're doing this. Doesn't mean it's going to
make 3.1, or that it must.
I've since started updating the spec, and the changes are very
straightforward and contained. You can see for yourself, most of the
changes are already in there.
I will look when time permits, before the next TC39 meeting.
Given this, the way I would like to proceed is towards a full and
complete proposal to be ready in time for people to review for the
Redmond meeting. It may very well need to be scaled back, but I
would
much rather be in a position where the edit requests that came
out of
that meeting were in the form of "prune this" rather than once again
be presented with "investigate that and report back".
How would a response of "take the time you need, and we'll track it
for Harmony; 3.1 is otherwise all but done" strike you?
Frankly, it sounds like moving the goal posts.
You think so? I respectfully disagree, and I've been in all the face-
to-face meetings. ES3.1 started in earnest this past January, with a
limit scope. Decimal (already in ES4 as proposed, with operators as
well as literal syntax) was not being pushed into ES3.1 until spring-
time, at which time 3.1 was supposed to be technically "done" in
July, finalized including editorial fussing and typography in
September, etc., for standardization at the December GA meeting.
Seems to me the push for Decimal moved some posts. Why is Decimal-or-
a-No-vote being hung like a sword over the committee's head? What
goes wrong if Decimal is not in 3.1, but is (especially with user-
feedback-based improvements) in the successor Harmony edition within
1-2 years?
When is spec freeze? When do we need to have implementations
complete? Are we planning to have these implementations usability and
field tested? Will adequate time be allowed to factor in feedback
that is received from these tests?
Let's get the implementations done and we'll see. There's no
deterministic top-down command -and-control schedule here. For the
open source implementations, the main thing is to get into nightly
builds, get docs and blogs educating users, gather bug reports.
I'm writing the spec. I've written one implementation -- or more
precisely a binding to an implementation that has been well tested and
made available under a very liberal license. I've run the performance
tests you asked me to run. I'm ready and willing to convert the
existing decNumber test suite over to whatever format is desired; I'm
also ready and willing to write additional tests to cover the ES
specific binding to these functions.
We should talk about landing your patch on Mozilla elsewhere. IIRC
Rob Sayre asked for a few things in the bug and I haven't seen your
response (I may have missed it; been busy lately).
The meanings of operators when all of the operands are decimal are
well specified by IEEE 754R. The meaning of equality in ES3 is a bit
arcane, and we've worked through that. My SpiderMonkey implementation
provides access to decNumber's compareTotal method, and Object.eq
(something Doug and Mark feel is necessary for other reasons) can be
defined in such a way as to make use of that function.
What's the Object.eq issue? I must have missed an 8am 3.1 call. :-/
What's left is figuring out is the syntax for constructing decimals
from strings (Decimal.parse sounds fine to me, how about you?), and
from binary64 floating point numbers (Number.toDecimal sounds fine to
me, how about you?).
I like those names, FWIW.
And to decide whether binary64 numbers get
converted to decimal128 when they are mixed, or if it is the other way
around.
That is important to get right. Igor Bukanov and I both sounded off
on this list as against any mixing of decimal128 and binary64 that
degraded toward binary64. So I'm pleased as punch with your new
thinking.
I was originally pursing the latter, but based on feedback,
I'm seriously considering the former -- with the proviso that the
conversions be exact and correct rounded, to the limits of the
precision supported by decimal128. This approach not only has the
advantage of being exact and correct, it also obviate the need for
"use decimal".
Maybe, except writing 123m all over is enough of a drag that most
people won't. There still could be a case for 'use decimal'.
How's the new approach (contagious decimal128) working out in the code?
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
