Spec proposal
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 Michael O'Brien ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Spec proposal
On Thu, 2007-12-13 at 08:07 -0800, Michael O'Brien wrote: I believe this is an important issue that will force non-standard implementations... On the same topic, it seems that Adobe are planning on introducing the decimal type into the Flash Player before the ES4 spec. is finalised. They're asking Flash developers at the moment what their requirements are for decimal math. Is the spec. at the point where implementers can start preempting it? Cheers, -- Nathan de Vries smime.p7s Description: S/MIME cryptographic signature ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Spec proposal
On Dec 13, 2007, at 3:09 PM, Nathan de Vries wrote: On Thu, 2007-12-13 at 08:07 -0800, Michael O'Brien wrote: I believe this is an important issue that will force non-standard implementations... On the same topic, it seems that Adobe are planning on introducing the decimal type into the Flash Player before the ES4 spec. is finalised. They're asking Flash developers at the moment what their requirements are for decimal math. Is the spec. at the point where implementers can start preempting it? Not quite, but no one is going to preempt -- the early implementors will have to shift if they want to claim conformance to the final spec. We've done this in the past in Mozilla and it has been tolerable. Michael's point seemed to me to be more about divergent long/ulong semantics and no spec, not early implementations trumped by the one true spec. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Spec proposal
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 Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Spec proposal
On Dec 14, 2007 5:54 AM, Michael O'Brien [EMAIL PROTECTED] wrote: 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? I'm saying that current ES3 implementations do this (int/uint representations overflow to double as needed in order to use the integer hardware and avoid using (software) fp) and that ES4 implementations will do the same. Decimal is really not part of that discussion. If so, then can an implementation be compliant if it: Has no floating point h/w or s/w If it has no floating point at all it can't be compliant with ES3. 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. My opinion is that subset implementations will exist in any case -- for example, ActionScript has no eval and no Function constructor -- and that the spec should not address these needs because the complexity cost in the spec is too great. If an implementation wants to do away with IEEE double numbers and use 64-bit ints instead, and do all the work with retrofitting libraries and so on and choose whether to support trig functions or not, then I think it's better if this cost is borne by the implementor or by a derivative standard, not by the ES4 spec, which is plenty complicated already. (Also note that TG1 rejected the previous proposal on use decimal (meaning pretend all numbers are decimal) because we did not think it could be made to work reliably. The same argument would go for any other number type IMO.) --lars 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 Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
