Re: Spec proposal

[Michael O'Brien]

Thanks for your explanations.  I think I understand your position, but I do respectfully disagree. Comments below: Lars T Hansen wrote: 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. Yes, and that is a problem.  A language fragments when segments can't easily be compliant. We want the path of least resistance to be compliance. We have an opportunity to embrace a large and growing market segment and permit implementations without floating point to be compliant with ES4.  ECMAScript should be more than the language of web browsers and browser plugins running on PCs. 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. I think we could make trig functions and floating point literals optional if floating point of some kind is not present.  Surely we could define simple semantics for when floating point is not present and allow such implementations?? I understand complexity can often grow and that the spec is already struggling with complexity. But I don't yet see the undue complexity with this proposal. It could just be my ignorance (I've got plenty of that), but I do want to push for this proposal to be adequately considered. (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.) Sorry, but I can't judge this argument without hearing the reasons. One possible solution is to avoid the "use number" approach and go with your scale up on overflow strategy. and adjust the ES4 spec to permit non-floating point implementations. ie. optional floating literals and floating library methods if floating point is not present. It would also be good to be able to sleuth at runtime if floating point is available. Michael --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