On Sat, Aug 23, 2008 at 10:48 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 23, 2008, at 10:47 AM, Sam Ruby wrote:
>
>> On Sat, Aug 23, 2008 at 1:12 PM, Mike Shaver
>> <[EMAIL PROTECTED]> wrote:
>>> On Sat, Aug 23, 2008 at 10:04 AM, Sam Ruby
>>> <[EMAIL PROTECTED]> wrote:
>>>> Decimal implemented as a library would be sufficient for a 3.1
>>>> release.
>>>
>>> Would it not be sufficient forever? It seems like that's the
>>> strategy
>>> that Java, Python and C are taking, as far as the Really Important
>>> Languages go. I'd be more comfortable getting experience based on an
>>> available library implementation before standardizing it, let alone
>>> standardizing a new native numeric type, but I'm not likely to move
>>> the committee needle.
>>
>> I don't believe we know the answer to that question. In any case, we
>> need to decide what the following will produce:
>>
>> Decimal.parse('2') + 3
>>
>> Furthermore, it seems inevitable to me that this topic will come up at
>> the next TC 39 meeting in Redmond. A minimal proposal, much along the
>> lines as the one you described above, was available for review in time
>> for the Oslo meeting, and resulted in a number of usability concerns
>> being expressed such as the one I described above.
>
> Especially since there was no effort (correct me if I'm wrong) to
> throw from ToPrimitive on the Decimal type. Either Decimal (an object
> type) converts to number, which loses precision and expressiveness,
> or it converts to string, which means + is forever after string
> concatenation given Decimal operands. That seems future-hostile, some
> of us said at the Oslo TC39 meeting.
>
> IOW if 3.1 were only to have a new Decimal standard library object
> type (like Date), it would have to be unusable except by method
> calls. It couldn't convert implicitly, even to string. IIRC I called
> that "unusably crufty" in Oslo; I hope I was quoted accurately :-P.
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.
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.
>> 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.
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?
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.
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 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?). And to decide whether binary64 numbers get
converted to decimal128 when they are mixed, or if it is the other way
around. 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".
> /be
- Sam Ruby
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
