use decimal

Maciej Stachowiak mjs at
Wed Sep 17 18:54:55 PDT 2008

On Sep 17, 2008, at 6:24 PM, Sam Ruby wrote:

> On Wed, Sep 17, 2008 at 8:05 PM, Maciej Stachowiak <mjs at>  
> wrote:
>> On Sep 17, 2008, at 4:48 PM, Sam Ruby wrote:
>> That approach sounds much better to me than Doug's proposal.
> Let's take that a step further.  If other languages are any guide,
> then complex, rational, and big integer are common requirements.  For
> the moment, let's assume that unlimited precision integer arithmetic
> is the most likely next "number-like" requirement for ES.  In Python
> such constants end with an "L", so I will use that to illustrate the
> next question.  But first some background.
> 9007199254740993 is the smallest positive integer that can't be
> exactly represented as a ES number.  9007199254740993L and
> 9007199254740992m, however can be represented exactly as hypothetical
> big integer and 128 bit decimal values.
> Given that as background, what should typeof(9007199254740993L)  
> return?

All of this depends on what identities we wish to preserve regarding  
typeof and various operators.

Other languages with a rich numeric tower have predicates for  
detecting any number in general, as well as specific types of numbers.  
I do not think this richness can all be expressed adequately via  
typeof's single string return. So I think such extensions to the  
numeric tower would call for proper type predicates and then typeof  
adjusted to do whatever is most sane in light of legacy code.

>>>> I agree with you and Brendan that these issues are better resolved
>>>> in Harmony.
>>> At the minimum, I would hope that we should be able to agree on what
>>> the issues are.  If they can't be worked in time, so be it.
>>> Doug has put forward the proposal that Harmony seek to "wholly
>>> replace the binary representation with the decimal representation".
>>> Is that the consensus of the group?
>> I certainly do not agree with his proposal. Other embers of the group
>> may speak for themselves, but it was not my understanding previously
>> that anyone wanted to go down such a road.
> Doug's previous proposal where "use decimal" merely determined whether
> a constant like "1.1" would be interpreted as binary64 or decimal128
> still may be worth exploring.  Presumably with the ability to have a
> suffix (like d) to explicitly indicate that a given quantity is double
> precision.
> But given the past history of this language, and the wide deployment
> is has enjoyed, I don't think that "use decimal" should ever mean much
> more than that.

I particularly would prefer that any dialect pragmas ("use strict" as  
much as "use decimal") should have effects that can all be explained  
as occuring at parse/compile time, rather than persistent runtime  
behavior effects. I have not closely reviewed strict mode for whether  
it satisfies this criterion.


More information about the Es-discuss mailing list