Adobe position paper on the ECMAScript 4 proposal space -- decimal

Lars Hansen lhansen at adobe.com
Thu Feb 28 07:20:25 PST 2008


> -----Original Message-----
> From: peterjoel at gmail.com [mailto:peterjoel at gmail.com] On 
> Behalf Of Peter Hall
> Sent: 28. februar 2008 16:08
> To: Lars Hansen
> Cc: Dick Sweet; Brendan Eich; es4-discuss Discuss; TC39; Mike 
> Cowlishaw
> Subject: Re: Adobe position paper on the ECMAScript 4 
> proposal space -- decimal
> 
> But do you really want to have to check the type at runtime? 
> That could hurt performance even in cases where the type was 
> never a decimal. Or do you intend to use early binding to 
> select the correct method? (ie. bind to Math.decimal::cos() 
> whenever the argument can be proven to be decimal, and bind 
> to the normal method otherwise).

Assume that the Math object is bound immutably and that its methods
are bound immutably too.  Then if the type of the argument to eg 
Math.cos is statically known to the compiler then a good 
implementation is clearly no worse off than it is now, it can
avoid all type checking. [*]

For the other case, assume there's a variable x whose type is
unknown, and then there's the call Math.cos(x).  In present code
that call requires a check on entry to cos() that x is a
primitive number (a double), with a fallback to conversion and
then a retry.  The common case is that the argument is a double.

In ES4 with decimal, the common case (absent a Big Red Switch for
decimal) is still that the argument is a double, so the code would
be written to handle that case well (check that it's double and
perform the operation; other valid types are handled on the
slow branch), and there would be no slowdown compared to the
existing case.

--lars

[*] In E262-3, the Math object is mutable and all its properties 
are mutable too, so there is pretty much nothing a traditional 
compiler can assume for portable code.  A tracing compiler (taking
into account run-time information) might do better but only if it
gets to grow the context large enough to collapse multiple checks
into one.  In ES4, we're making the Math binding immutable (or
we're providing an immutable intrinsic::Math, I forget the exact
resolution), and it will have immutable intrinsic bindings.  So
in practice, both traditional and tracing compilers will be able
to do better than in ES3.

  
> 
> Peter
> 
> 
> On Thu, Feb 28, 2008 at 2:43 PM, Lars Hansen 
> <lhansen at adobe.com> wrote:
> > > -----Original Message-----
> >  > From: Dick Sweet
> >
> > > Sent: 27. februar 2008 23:27
> >  > To: Lars Hansen; 'Peter Hall'
> >  > Cc: 'Brendan Eich'; 'es4-discuss Discuss'; 'TC39'; 'Mike 
> Cowlishaw'
> >  > Subject: RE: Adobe position paper on the ECMAScript 4  > 
> proposal 
> > space -- decimal  >
> >
> > > Lars is correct.  If you can declare decimal literals, that
> >  > is enough to get you into decimal arithmetic.  The various  > 
> > automatic coercions will do the rest, though as he said, type  > 
> > annotations could reduce the scope of errors.  You would 
> also  > need 
> > some static methods on decimal like exp and log, since  > 
> the ones on 
> > Number expect doubles.
> >
> >  The current thinking for ES4 is that all the Math methods are  
> > polymorphic and would return decimal results for decimal 
> inputs (and 
> > int  results for int inputs when that makes sense).  There 
> could be  
> > corresponding monomorphic methods on double and decimal, too, of 
> > course,  but that's not been brought up.
> >
> >
> >
> >  >
> >  > Dick
> >  >
> >  > -----Original Message-----
> >  > From: Lars Hansen
> >  > Sent: Wednesday, February 27, 2008 1:54 PM  > To: Peter 
> Hall; Dick 
> > Sweet  > Cc: Brendan Eich; es4-discuss Discuss; TC39; Mike 
> Cowlishaw  
> > > Subject: RE: Adobe position paper on the ECMAScript 4  > proposal 
> > space -- decimal  >  > There's no such rule in ES4.  There are 
> > implicit conversions  > among primitive number types, and between 
> > primitive types and  > wrapper types, and those kick in 
> when storing 
> > something in an  > annotated location.  So these two programs are 
> > different, and  > both are correct:
> >  >
> >  >   var s = "foo"
> >  >   var t = 10.5
> >  >
> >  > and
> >  >
> >  >   var s : String = "foo"
> >  >   var t : int = 10.5
> >  >
> >  > (Decimal makes sense without any type annotations, but  > 
> > annotations probably cause coercions to decimal to happen  > more 
> > often and thus reduce the scope for error.  I assume  > 
> this is what 
> > Dick meant.  But 1m would be a decimal value 1,  > and 1m/10 would 
> > convert 10 to decimal before dividing -- no  > annotations 
> involved.)  
> > >  > --lars  >  > > -----Original Message-----  > > From: 
> > es4-discuss-bounces at mozilla.org  > > 
> > [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Peter 
> Hall  > > 
> > Sent: 27. februar 2008 22:29  > > To: Dick Sweet  > > Cc: Brendan 
> > Eich; es4-discuss Discuss; TC39; Mike Cowlishaw  > > Subject: Re: 
> > Adobe position paper on the ECMAScript 4  > proposal space  > > -- 
> > decimal  > >  > > OK. Decimal type just makes sense to me. 
> And I think 
> > this  > is one case  > > where I think you can break "the 
> rule" that 
> > says correct type  > > annotations do not affect the program.
> >  > >
> >  > > Peter
> >  > >
> >  > >
> >  > > On Wed, Feb 27, 2008 at 9:10 PM, Dick Sweet 
> <sweet at adobe.com> wrote:
> >  > > > A couple of comments from the fellow who did the trial  > > 
> > implementation  > > > of  decimal in Tamarin.
> >  > > >
> >  > > >  It would be pretty easy to have decimal if you have to  > 
> > explicitly  > > > declare variables of that type and need to 
> > explicitly  > > denote literals  > > > that you want to be decimal 
> > with the "m" suffix.  Such denotation  > > > would  not be 
> necessary 
> > for literals without fractional  > > parts, unless  > > > they are  
> > beyond the range of integer representation within  > > a double.
> >  > > > Promotion  of arithmetic to decimal in mixed situations  > > 
> > isn't that hard to do.
> >  > > >
> >  > > >  Dick
> >  > > >
> >  > > >
> >  > > >  -----Original Message-----
> >  > > >  From: Brendan Eich [mailto:brendan at mozilla.org]  > 
> > >  Sent: 
> > Wednesday, February 27, 2008 10:58 AM  > > >  To: Peter 
> Hall  > > >  
> > Cc: es4-discuss Discuss; TC39; Mike Cowlishaw  > > >  Subject: Re: 
> > Adobe position paper on the ECMAScript 4  > > proposal 
> space  > > > --  
> > decimal  > > >  > > >  > > >  > > > On Feb 27, 2008, at 10:40 AM, 
> > Brendan Eich wrote:
> >  > > >
> >  > > >  > First, nothing's "ruled out" -- you're asking the 
> wrong  > > 
> > guy if you  > > > > want Adobe's position, but see Lars's reply to 
> > Mike Cowlishaw:
> >  > > >  > decimal as a type without any implicit 
> literal/operators  > 
> > > mode is  >  > > > still possible,  > > >  > > >  I should have 
> > written "without generic operator methods"
> >  > > -- ES4 could
> >  > > > still have a decimal type and built-in operators and  > > 
> > literal support,  > > > but no modal defaulting (no "big 
> red switch").
> >  > > >
> >  > > >  /be
> >  > > >
> >  > > >
> >  > > _______________________________________________
> >  > > Es4-discuss mailing list
> >  > > Es4-discuss at mozilla.org
> >  > > https://mail.mozilla.org/listinfo/es4-discuss
> >  > >
> >  >
> >  _______________________________________________
> >  Es4-discuss mailing list
> >  Es4-discuss at mozilla.org
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
> 



More information about the Es4-discuss mailing list