Mark S. Miller
erights at google.com
Wed Sep 17 18:58:44 PDT 2008
On Wed, Sep 17, 2008 at 6:24 PM, Sam Ruby <rubys at intertwingly.net> wrote:
> 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?
If we adopt Sam's current position, where typeof 1m === 'decimal', then I
think we're stuck with typeof 1L === 'integer' or something. Likewise
'complex', 'rational', 'matrix', 'unreal', 'quaternion', etc. If we adopt my
preferred position that typeof 1m === 'number', then typeof 1L and these
others should be 'number' too.
In both cases, it would seem that new numeric types must still be added by
the language's providers rather than the language's users. This is the
tragic constraint that none of the present proposals have been able to
escape. I would much rather see us work on that problem, rather than trying
to decide what is the next numeric type we language designers need to cook
> 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
> 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 agree that the "use decimal" pragma should determine nothing other than
the interpretation of unqualified numeric constants. However, "d" is a
terrible choice for a suffix meaning "binary floating point", because in
effect it means "not *d*ecimal". It is anti-mnemonic.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss