On Sep 17, 2008, at 6:24 PM, Sam Ruby wrote:
> On Wed, Sep 17, 2008 at 8:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
> 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.
Regards,
Maciej
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
