Lars,
I'm not sure quite what you are saying here.
Are you saying that ES4 should automatically scale numerics up
seamlessly from integer to decimal by detecting overflow much as Ruby
does?
ie. the default number type is not decimal, but rather the numeric type
will expand as required up to 128 bit decimal numbers. Is this what you
are saying?
If so, then can an implementation be compliant if it:
- Has no floating point h/w or s/w
- Has no decimal
ie. could an implementation be compliant if it does not support
floating point arithmetic and can only scale up to 32 or 64 bit
integers?
This is what many embedded devices need. I think the spec should
accommodate these devices without breaking the spec.
Michael
Lars T Hansen wrote:
On Dec 13, 2007 5:07 PM, Michael O'Brien <[EMAIL PROTECTED]> wrote:
I understand that the cut off for proposals is long past. But I believe
this is an important issue that will force non-standard implementations
.... bad.
Proposal:
Running ECMAScript on embedded devices is more and more common. It is
being used in mobile phone widget engines, mobile browsers and it a wide
variety of embedded infrastructure hardware. However many such devices
do not have floating point and this has forced non-standard language
extensions to allow other default numeric types. For example: most
feature phones (> 500M devices) do not have floating point and have very
modest CPU resources. Furthermore, the proposed ES4 decimal standard is
currently implemented in software as there is no common hardware support
for it (yet). Consequently, it is fairly large and slow and will
certainly put a strain on feature phones!
We should allow the default number type to be an integer or 64 bit
integer. Many of embedded devices have very good 64bit integer support
that is quite fast. 64 bit integer support is important if floating
point or decimal is not available to provide a wider scale of numeric
values.
To do this, I'd like to propose that:
1. We change the "use decimal" pragma to "use number NUMBER_TYPE". This
would allow for other number types. E.g.
use number decimal
use number int
2. We add support for int as the default number
3. We add "long" and ulong types that are by definition 64 bit. Also
support "use number long"
I have a couple of comments.
First, the "use decimal" pragma has been changed radically from older
proposals and no longer allows the program to select "decimal
everywhere" semantics. (What it does allow is a little bit in flux.
At a minimum it allows controlling rounding and precision.)
Second, several good implementations of ES3 fall back on double
arithmetic sparingly in practice by using clever representations; for
example, "1" is represented as an int, "1 + 2" uses int arithmetic
only (with an overflow check). The same trick could be used if the
default were decimal. An implementation could extend this principle
up to 53 bits of precision, after which it would have to go to
floating point or become very clever. "53 bits ought to be enough for
anyone." (Making all its values decimal would give the program in
excess of 100 bits of integer precision ;-)
My beef with ECMAScript at this point is that it has no integer divide
operator and no easy way to signal to the implementation that that's
what desired. In practice, "/" forces us into floating point.
--lars
|
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
