Why decimal?

[Brendan Eich-3]

On Jun 24, 2009, at 9:58 AM, Christian Plesner Hansen wrote:

>> I have concluded that it's too late to "fix" anything by adding  
>> decimal.
>> It's clearly to late to change the number type from binary to  
>> decimal. So we
>> are going to let library authors cater to users, and get TC39 out  
>> of this
>> hopeless business.
>
> Sorry for being slow but I'm a little unclear on what that means.
> Does it mean that you're not in favor of including decimal in harmony?

The second message in this thread, my first reply to your head-of-
thread message, said:

"Anyway, decimal is not being pushed into JS at this point. At the  
last face-to-face TC39 meeting, we changed direction to explore  
generalizing value type support (including operators and literals if  
we can) so that libraries could add first class number-like types."

https://mail.mozilla.org/pipermail/es-discuss/2009-June/009553.html

/be




_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[rubys]

Erik Corry wrote:

>
> 2009/6/23 Brendan Eich <brendan@... <mailto:brendan@...>>
>
>     On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:
>
>>     I've been looking around on the web for reasons why decimal arithmetic
>>     should be added to ES.  The most extensive page I could find was
>>     http://speleotrove.com/decimal/decifaq.html.  If anyone know other
>>     good sources of information about decimal and its inclusion in ES
>>     please follow up.
>
>     Mike Cowlishaw's pages on decimal have lots of arguments for it:
>
>     http://www2.hursley.ibm.com/decimal/decifaq.html
>     http://www2.hursley.ibm.com/decimal/
>
> I'm afraid both these links seem to have broken.

The content can now be found on Mike's site:

http://speleotrove.com/decimal/decifaq.html
http://speleotrove.com/decimal/

- Sam Ruby
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

> The second message in this thread, my first reply to your head-of-thread
> message, said:
>
> "Anyway, decimal is not being pushed into JS at this point. At the last
> face-to-face TC39 meeting, we changed direction to explore generalizing
> value type support (including operators and literals if we can) so that
> libraries could add first class number-like types."

I am just as unsure of how to read that.  Does "at this point" mean
that it's off the table altogether for harmony or only that it's been
postponed until later in the process?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:

>> The second message in this thread, my first reply to your head-of-
>> thread
>> message, said:
>>
>> "Anyway, decimal is not being pushed into JS at this point. At the  
>> last
>> face-to-face TC39 meeting, we changed direction to explore  
>> generalizing
>> value type support (including operators and literals if we can) so  
>> that
>> libraries could add first class number-like types."
>
> I am just as unsure of how to read that.  Does "at this point" mean
> that it's off the table altogether for harmony or only that it's been
> postponed until later in the process?

Why do you want a for-all-time declaration from me?

We can only focus on what's next. Our covenants the proscribe certain  
features are few: no ES4-style namespaces (Common Lisp packages), nor  
packages built on them.

If we standardize extensible value types and a decimal extension  
becomes so popular it should be part of the normative core language  
(as JSON is now, different kind of extension but same rationale for  
making it part of the normative core), then why would we not include  
decimal?

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:

> We can only focus on what's next. Our covenants the

s/the/that/

> proscribe certain features are few: no ES4-style namespaces (Common  
> Lisp packages), nor packages built on them.

I reviewed the Harmony announcement message:

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html

The other proscribed feature was "early binding" in the sense of  
static checking that made name binding and optional type annotation  
judgments when compiling, and enforced them by failing compilation.  
But this is either too vague or, if taken too literally, undesirable.  
For Harmony we are looking at opt-in lexical scope, which would make  
free variable uses into static errors:

http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope

As this wiki page says, the syntax is not crucial, but the idea of  
removing the global object from the scope chain, of having only  
lexical frames, is very much on the Harmony agenda. In such an opt-in  
regime, early binding is possible and may be indistinguishable from  
any binding.

The other kind of "early binding" ES4 did was of standard constructor  
names in the global object when used as type annotations, by  
implicitly opening the intrinsic namespace. This also early-bound  
method names such as charAt on a statically typed string variable, or  
a string literal.

This kind of early binding of names, creating an evaluation model that  
is different from the usual one for names in expressions, is really  
what the Harmony message meant to proscribe. TC39 agrees now to make  
any optional type annotations evaluate dynamically (implementations  
may partially evaluate as an optimization).

I admit it is hard to make precise statements that ban certain areas  
of extension from ever being entertained by TC39, but I think that's a  
good sign that we shouldn't close our minds excessively. The main  
agreements were about getting controversial ES4 ideas, which were  
already being removed from ES4 (packages went in April 2008), off the  
table.

Again, there is no reason for us to "ban" decimal forever. That would  
be wrong on several levels, most obviously because we would  
standardize a popular decimal value type library if it emerged.

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 12:13 PM, Brendan Eich wrote:

> On Jun 24, 2009, at 12:08 PM, Christian Plesner Hansen wrote:
>
>> I am just as unsure of how to read that.  Does "at this point" mean
>> that it's off the table altogether for harmony or only that it's been
>> postponed until later in the process?
>
> Why do you want a for-all-time declaration from me?

Sorry, I overreacted and changed timeframe from your "harmony" to "all-
time".

For Harmony, which is also ill-defined but may mean exactly ES6, I  
would be surprised if we both standardize value types and see a  
decimal library become so popular it merits inclusion in the core  
language.

If Harmony [Middle English armonie, from Old French, from Latin  
harmonia, from Greek harmoniā, articulation, agreement, harmony, from  
harmos, joint.] extends beyond ES6 in some way we should rename it.

Of course we hope that the committee will operate harmoniously for a  
good long time, but we have other musical tropes to abuse ;-).

So let's say ES6 is Harmony. Once again I do not wish to "ban" decimal  
from ES6 but it is not on the committee's agenda, and members do not  
want to standardize it in a "hardcoded" fashion, so value types come  
first, and may be the only extension relevant to decimal in ES6.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 12:37 PM, Brendan Eich wrote:

> So let's say ES6 is Harmony.

Last message from me on this topic today, I promise.

I wanted to encourage the use of "Harmony" for what's next, over  
against "ES6". The ES3.1 -> ES5 experience, and of course many  
software release renumbering adventures from our collective  
professional and open source lives, teach us to avoid burning numbers  
in SiO2 prematurely. Ecma wants whole edition numbers, ISO tracks  
those. There could be a reason to do a fast ES6 that is not "Harmony".

So don't early-bind to ES6 :-P.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

Good thing you caught me before I'd sent my reply :-P.

If decimal isn't being actively pursued I'll give the anti-decimal
propaganda machine a break.  And if it does turn out that decimal
becomes a popular extension I'll happily accept that I've been proven
wrong and be all for including it in the language.


-- Christian

> Sorry, I overreacted and changed timeframe from your "harmony" to
> "all-time".
>
> For Harmony, which is also ill-defined but may mean exactly ES6, I would be
> surprised if we both standardize value types and see a decimal library
> become so popular it merits inclusion in the core language.
>
> If Harmony [Middle English armonie, from Old French, from Latin harmonia,
> from Greek harmoniā, articulation, agreement, harmony, from harmos, joint.]
> extends beyond ES6 in some way we should rename it.
>
> Of course we hope that the committee will operate harmoniously for a good
> long time, but we have other musical tropes to abuse ;-).
>
> So let's say ES6 is Harmony. Once again I do not wish to "ban" decimal from
> ES6 but it is not on the committee's agenda, and members do not want to
> standardize it in a "hardcoded" fashion, so value types come first, and may
> be the only extension relevant to decimal in ES6.
>
> /be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark Miller-2]

On Wed, Jun 24, 2009 at 12:43 PM, Brendan Eich <brendan@...> wrote:

On Jun 24, 2009, at 12:37 PM, Brendan Eich wrote:

So let's say ES6 is Harmony.

Last message from me on this topic today, I promise.

Aha! Carte blanche to have the last word of the day! Better seize while it's hot.
Just kidding ;)

 

I wanted to encourage the use of "Harmony" for what's next, over against "ES6". The ES3.1 -> ES5 experience, and of course many software release renumbering adventures from our collective professional and open source lives, teach us to avoid burning numbers in SiO2 prematurely. Ecma wants whole edition numbers, ISO tracks those. There could be a reason to do a fast ES6 that is not "Harmony".

So don't early-bind to ES6 :-P.

As I think Allen first suggested (please correct if I misattribute or misconstrue), I have been using "Harmony" to label the trajectory that the Harmony agreement set us on. I have been using "ES6" to name whatever the next concrete spec edition will be that emerges from our agreed trajectory. No matter how fast or slow ES6 is, many of the things currently hoped for under the Harmony banner will not make it into the next concrete edition.

--

   Cheers,
   --MarkM


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Erik Arvidsson]

On Wed, Jun 24, 2009 at 13:46, Mark Miller<erights@...> wrote:
> As I think Allen first suggested (please correct if I misattribute or
> misconstrue), I have been using "Harmony" to label the trajectory that the
> Harmony agreement set us on. I have been using "ES6" to name whatever the
> next concrete spec edition will be that emerges from our agreed trajectory.
> No matter how fast or slow ES6 is, many of the things currently hoped for
> under the Harmony banner will not make it into the next concrete edition.

I want to second that. The list of features we agreed on at the last
F2F was a bit too long for my liking. I think it is more reasonable to
do the new spec (with a RI) and just add a few of those features in a
faster iteration. I have my opinion on which those features are but l
would rather save that discussion for the next face to face meeting.

--
erik
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 25, 2009, at 9:56 AM, Erik Arvidsson wrote:

> On Wed, Jun 24, 2009 at 13:46, Mark Miller<erights@...> wrote:
>> As I think Allen first suggested (please correct if I misattribute or
>> misconstrue), I have been using "Harmony" to label the trajectory  
>> that the
>> Harmony agreement set us on. I have been using "ES6" to name  
>> whatever the
>> next concrete spec edition will be that emerges from our agreed  
>> trajectory.
>> No matter how fast or slow ES6 is, many of the things currently  
>> hoped for
>> under the Harmony banner will not make it into the next concrete  
>> edition.
>
> I want to second that. The list of features we agreed on at the last
> F2F was a bit too long for my liking. I think it is more reasonable to
> do the new spec (with a RI) and just add a few of those features in a
> faster iteration. I have my opinion on which those features are but l
> would rather save that discussion for the next face to face meeting.

You're right, the Harmony agenda is big enough that in all likelihood  
it won't fit into one edition.

I was arguing against coupling to editions for several reasons, but I  
backed off on calling this outcome because of the tension between  
integrated design and triage to fit a standards process.

To argue against the extreme point at risk here, we want more than  
barely treading water by switching to a new spec formalism.  
Standardization overhead is high enough that amortizing the real work  
over too many editions makes for too little progress relative to  
chunkier editions.

Plus, smaller path-dependent hops can paint us into corners that we  
can't get out of due to progressive compatibility constraints.

I hate to say more without data, so let's proceed and see how it goes.

On the spec formalism / reference implementation front, the good news  
is that we will have help from Dave Herman and Sam Tobin-Hochstadt (http://www.ccs.neu.edu/home/samth/ 
).

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss