Re: Default argument values
On Feb 27, 2008, at 6:56 PM, Steven Mascaro wrote:
> 2008/2/28 Brendan Eich <[EMAIL PROTECTED]>:
function h({p:x,q:y} = {p:3,q:4}) [x,y]
h()
>> 3,4
>
> Unfortunately, it doesn't work when you want to specify a subset of
> the optional parameters. e.g.:
>
>>> h({p:1})
> 1,
True -- it's not the same as named parameters, for sure.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Default argument values
On Feb 27, 2008, at 6:35 PM, Steven Mascaro wrote:
>> This is not to knock named parameters, just to explain why they
>> never
>> made it into a serious proposal in the modern ES4 era.
>
> That sounds fine. The only thing it misses is interchanging positional
> and named parameters, but that's no big deal. Will default values work
> by doing the following?
>
> function foo({option1, crud2, frob} = {option1: 1, crud2: "dirty",
> frob: "enius"}) { ... }
That should work.
> A bit cumbersome, but otherwise OK. I tried in the RI, but it throws a
> ParseError. Though both the following give the same error as well:
>
> function foo({option1, curd2, frob}) {}
> ({x, y} = {x: 42, y: 37})
That object destructuring shorthand was approved at
http://bugs.ecmascript.org/ticket/111
but I don't see a ticket, or morph of 111, asking for RI
implementation. It's not yet implemented:
>> function f({p:x,q:y}) [x,y];
>> f({p:1,q:2})
1,2
>> function g({p,q}) [p,q]
**ERROR** ParseError: unknown token in destructuringField (near :1:1-1.8)
but as shown above, the longhand form works, and so do default
parameters:
>> function h({p:x,q:y} = {p:3,q:4}) [x,y]
>> h()
3,4
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Default argument values
2008/2/28 Brendan Eich <[EMAIL PROTECTED]>:
> I search like so:
>
> http://www.google.com/search?hl=en&q=site%3Amail.mozilla.org+es4-
> discuss+%22named+parameters%22+brendan
Ah. I kept searching for variants of 'default parameters'.
> This is not to knock named parameters, just to explain why they never
> made it into a serious proposal in the modern ES4 era.
That sounds fine. The only thing it misses is interchanging positional
and named parameters, but that's no big deal. Will default values work
by doing the following?
function foo({option1, crud2, frob} = {option1: 1, crud2: "dirty",
frob: "enius"}) { ... }
A bit cumbersome, but otherwise OK. I tried in the RI, but it throws a
ParseError. Though both the following give the same error as well:
function foo({option1, curd2, frob}) {}
({x, y} = {x: 42, y: 37})
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Default argument values
On Feb 27, 2008, at 5:22 PM, Steven Mascaro wrote:
> Anyway, I'm sure you know the advantages (and disadvantages?) to
> optional named arguments. I was just wondering whether they had been
> considered for ES4, or if considered and rejected, then why. I've
> searched the wiki and mailing list, but couldn't find anything. I also
> remember some brief comments on it a short while ago, but can't find
> them now.
I search like so:
http://www.google.com/search?hl=en&q=site%3Amail.mozilla.org+es4-
discuss+%22named+parameters%22+brendan
and found a thread where I sounded off on named parameters:
https://mail.mozilla.org/pipermail/es4-discuss/2007-March/000548.html
Already you see people burning an object per call to simulate named
parameters:
foo({option1: "on", crud2: "dunno", frob: 42})
With destructuring parameters and unambiguous callsites, the object
can be optimized away. There are other ways to optimize such objects
away, for the sake of ES3 code. Point is we have never mustered a
named parameter proposal in the face of existing practice that makes
do without, and new forms such as destructuring parameters:
function foo({option1, crud2, frob}) { ... }
that reduce the pressure for named parameters, and have their own
wins and motivations aside from named parameter ones.
This is not to knock named parameters, just to explain why they never
made it into a serious proposal in the modern ES4 era.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Default argument values
> Functions can take optional arguments (they have default values) and
> rest arguments:
>
> function f(x, y=0) { ... } // y is optional
>
What is the opinion on Python-style named arguments? i.e.:
def f(x = 0, y = 0):
...
f(y = 2)
The calling syntax for ES4 would obviously have to be different (is a
':=' operator too incongruous in ES4?).
I find I rarely use unnamed optional arguments, because once you have
more than 1, they become very awkward to deal with. In the past, I
invariably found myself writing code like this (in PHP):
function f($a, $b = null, $c = null, $d = D_DEFAULT) {
if ($b==null) { $b = B_DEFAULT; }
if ($c==null) { $c = C_DEFAULT; }
}
I would then call the function this way:
f(A_VALUE, null, null, D_VALUE);
Which would get very confusing with a large number of optional arguments:
f(A_VALUE, null, null, null, null, null, null, VALUE);
Now instead I try to write functions that take a php array for
optional arguments:
function f($a, $opts = array(), $b = B_DEFAULT, $c = C_DEFAULT, $d =
D_DEFAULT) {
extract($opts);
}
and call it like this:
f(A_VALUE, array("d" => D_VALUE));
The Python syntax is obviously far more elegant in both cases (and, I
assume, would be faster to run as it would have no extra runtime
overhead over positional arguments).
Besides syntactic simplicity and elegance, I also use named arguments
for 'self-documenting' code (both when arguments are mandatory and
optional). For example, I might write things like this in Python if I
feel I need to make things clear:
drawBox(x = 0, y = 0, width = 45, height = 70)
copy(source = fileA, dest = fileB)
Anyway, I'm sure you know the advantages (and disadvantages?) to
optional named arguments. I was just wondering whether they had been
considered for ES4, or if considered and rejected, then why. I've
searched the wiki and mailing list, but couldn't find anything. I also
remember some brief comments on it a short while ago, but can't find
them now.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Access to spreadsheet
On Feb 27, 2008, at 4:48 PM, Waldemar Horwat wrote: > Most of the categories are quite fine-grained in the spreadsheet. > The other kinds of types are in there, so tuples should be listed > as well or the entry renamed "Array and Tuple types". It's mighty > confusing otherwise. Renaming to elaborate is ok by me, but "tuple" is confusing too. There is no tuple type in JS (we passed up an opportunity doing ES1, Guy Steele pointed to it so we could mourn jointly: we kept the C comma operator instead of reserving it for tuple expressions). "tuple" in the ES 4 sense is an Array structural type of length > 1, guaranteeing at least those fixture types at the given element positions. It's still a kind of Array structural type. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Access to spreadsheet
Brendan Eich wrote: > On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote: > >> I'd like write access to the spreadsheet so we can fill in the Google >> column: >> >> http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2 >> >> Also, some features have been omitted from the spreadsheet, such as >> tuple types. Are those out of the language? > > It's not that fine-grained. Array types under Structural types includes > homogeneous array types (e.g, [int]) and tuple types ([boolean, string]). Most of the categories are quite fine-grained in the spreadsheet. The other kinds of types are in there, so tuples should be listed as well or the entry renamed "Array and Tuple types". It's mighty confusing otherwise. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Access to spreadsheet
On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote: > I'd like write access to the spreadsheet so we can fill in the > Google column: > > http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2 > > Also, some features have been omitted from the spreadsheet, such as > tuple types. Are those out of the language? It's not that fine-grained. Array types under Structural types includes homogeneous array types (e.g, [int]) and tuple types ([boolean, string]). Speaking only for myself, the color-based "voting" works only to where there are separable and generally independent proposals. You can't vote off tuples without redoing other things that depend on them, so I'd rather we not split them in the spreadsheet at this time. Another thing about the spreadsheet voting: it should not be taken to disenfranchise people on es4-discuss. It's helpful for a sense of the committee, but not decisive. IMHO! /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Access to spreadsheet
I'd like write access to the spreadsheet so we can fill in the Google column: http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2 Also, some features have been omitted from the spreadsheet, such as tuple types. Are those out of the language? Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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. 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
FW: Adobe position paper on the ECMAScript 4 proposal space -- decimal
My first attempt to reply bounced from es4-discuss since I wasn't subscribed. -Original Message- From: Dick Sweet Sent: Wednesday, February 27, 2008 1:10 PM To: 'Brendan Eich'; Peter Hall Cc: es4-discuss Discuss; TC39; Mike Cowlishaw Subject: RE: Adobe position paper on the ECMAScript 4 proposal space -- decimal 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:[EMAIL PROTECTED] 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Adobe position paper on the ECMAScript 4 proposal space -- decimal
On Feb 27, 2008, at 10:25 AM, Peter Hall wrote: > Was decimal ruled out as its own type? 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, although the Adobe position paper defers it. As Lars noted, it even has a trial implementation in Tamarin. Second, decimal is in the RI as proposed, more or less. Finally, whatever we do, we won't make certain BigMistakes. I wrote a long time ago in http://wiki.ecmascript.org/doku.php?id=discussion:decimal citing the amusing Cameron Purdy blog post at http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1 The first comment: > At a client gig, they were doing business/financial coding, so were > using BigDecimal. > > Of course, .add() and friends is too difficult, so they ended up > with roughly: > > BigDecimal subA = ... > BigDecimal subB = ... > > BigDecimal total = new BigDecimal( subA.doubleValue() + > subB.doubleValue() ); > > It was beautiful. > > Posted by Bob McWhirter on October 31, 2005 at 08:17 AM EST # is horrifying testimony to the need for operator and literal syntax, if not implicit modal defaulting. If we keep decimal in ES4, it will have operators and literal support. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Adobe position paper on the ECMAScript 4 proposal space -- decimal
Was decimal ruled out as its own type? Peter On Wed, Feb 27, 2008 at 5:58 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote: > > > None of the above speaks to the possibility that "decimal" might be > > a distinct data type in the language, of course, along with > > "double" and "int" and "uint". Such a data type would in our > > opinion not be a poor fit for ES4, and as your own writings > > demonstrate, there are good use cases for it. We think a few of > > our customers, and probably a few users on the web, would find the > > data type useful. > > I agree with what Lars wrote, except here I think the value of a > hypothetical (possibly mythical) "big red switch" is understated. > That most dup'ed JS bug in buzilla.mozilla.org, > > https://bugzilla.mozilla.org/show_bug.cgi?id=5856 > > still collects dups at a good clip. There was even a recent variation > complaining about mantissa binary precision limits, but that's not > the common problem. The common problem is that you can't do "dollars > and cents" or "pounds and pennies" arithmetic and get the "right > answer": > > js> 74.96-39.96 > 34.99 > > This is not a problem for only a "few users on the web". I wish we > could fix it. But the big red switch can't be on the side of the > whole browser, or even the current tab or window (and all its > subsidiary frames or iframes or popups). > > Mike, have you any experience with mixed mode (due to mixed code) > environments? > > /be > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft meta-issues
On Feb 27, 2008, at 9:00 AM, Lars Hansen wrote:
> Meta-level methods
>
> The predefined namespace "meta" is used for methods that
> participate in
> language-level protocols: invocation and property access and
> update. A
> class that defines meta::invoke is callable as a function (the
> meta::invoke method is invoked in response to the call); the
> meta::get,
> meta::set, meta::has, and meta::delete methods are invoked in response
> to accesses to non-fixture properties on the object.
Pedantry alert, forgive me -- but it may be important to know that
meta::invoke has static and instance forms.
Given class C { ... meta static function invoke(...) ... }, you can
call C as a function:
x = y + C(z);
This is used, e.g., by class Date in builtins/Date.es.
If you define a non-static function (a method) named meta::invoke
(via class C { ... meta function invoke(...) ... }), then as with
meta::get, etc., it is the instances of C that are themselves callable:
c = new C;
x = y + c(z);
So there's a meta function invoke(...) ... in class Function in the
RI's builtins/Function.es, for example.
HTH,
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Adobe position paper on the ECMAScript 4 proposal space -- decimal
On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote: > None of the above speaks to the possibility that "decimal" might be > a distinct data type in the language, of course, along with > "double" and "int" and "uint". Such a data type would in our > opinion not be a poor fit for ES4, and as your own writings > demonstrate, there are good use cases for it. We think a few of > our customers, and probably a few users on the web, would find the > data type useful. I agree with what Lars wrote, except here I think the value of a hypothetical (possibly mythical) "big red switch" is understated. That most dup'ed JS bug in buzilla.mozilla.org, https://bugzilla.mozilla.org/show_bug.cgi?id=5856 still collects dups at a good clip. There was even a recent variation complaining about mantissa binary precision limits, but that's not the common problem. The common problem is that you can't do "dollars and cents" or "pounds and pennies" arithmetic and get the "right answer": js> 74.96-39.96 34.99 This is not a problem for only a "few users on the web". I wish we could fix it. But the big red switch can't be on the side of the whole browser, or even the current tab or window (and all its subsidiary frames or iframes or popups). Mike, have you any experience with mixed mode (due to mixed code) environments? /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
ES4 draft meta-issues
Hi all,
Over the next several weeks I'll be sending out draft specs for all(?)
the ES4 library classes, one class at a time (in the order I get to
them).
The ES4 library is expressed in terms of ES4 fragments: the spec uses
executable -- and tested -- ES4 code in places where the ES3 spec uses
pseudocode. As a consequence, the draft library spec makes some
assumptions about what ES4 will look like when it's finished.
Below I am going to outline some aspects of ES4 that it will be useful
for the readers of the draft specs to know, beyond what's in ES3. This
outline will be updated from time to time as new draft specs require it.
(Probably much of the information here is already written up in the
language overview available on ecmascript.org, so go there for the full
story.)
Namespaces, names
ES4 puts all names into namespaces. A name is in exactly one namespace
and it is placed in that namespace by prefixing the binding keyword for
the name (class, var, const, function, and others) with the namespace
name. If MyNS is a namespace then
MyNS var x
creates a variable whose fully qualified name is "MyNS::x".
There are several predefined namespaces. The namespace "__ES4__" is
used for all top-level names that are new to ES4 if they're not in one
of the other namespaces (except for the name "__ES4__" itself, which is
the only unqualified top-level name introduced by ES4). Important
predefined namespaces are "__ES4__::intrinsic" and "__ES4__::reflect".
In order to avoid having to fully qualify names all the time, namespaces
can be opened; the names defined in the namespace will then be available
without qualificiation. The namespace "__ES4__" is opened for all ES4
code, so in practice the two predefined namespaces listed above are
known just as "intrinsic" and "reflect". (Opening a namespace may
introduce ambiguities, which can be resolved by fully qualifying
ambiguous names. Ambiguities are not common because a namespace opened
in an inner lexical scope takes precedence over namespaces opened in
outer scopes.)
The intrinsic namespace is reserved; user code is not allowed to
introduce new names in this namespace. The intrinsic namespace is used
primarily for methods in the predefined classes. For every prototype
method M there is a corresponding intrinsic method M in the class. For
example, there is Array.prototype.concat and also an intrinsic::concat
method on Array instances. The prototype methods are fully compatible
with ES3 in the types they accept and how they convert values. The
intrinsic methods normally have more tightly constrained signatures and,
like all class methods, are immutable (though they can be overridden in
subclasses -- that's allowed even for user code).
The intrinsic namespace provides integrity (code that calls an intrinsic
method will know that it references the original method, it is not at
the mercy of changes to the prototype method) and optimization
opportunities (early binding to the slot that holds the method in the
presence of type annotations). The specification of the predefined
classes in terms of ES4 code makes use of other predefined classes and
their methods, and predefined methods are careful to call intrinsic
methods to invoke known behavior and to call public methods to invoke
explicitly variant behavior. Normally, such invocations are always
explicitly qualified in the text in order to avoid any ambiguity in the
reader's mind.
Types and annotations
Bindings in ES4 are typed, and the type can be provided explicitly by
following the name with a colon and the type:
var x: Array
If the type is omitted, it is "*" (read as "any"), which means it is
unconstrained. If we assume just run-time type checking for the time
being, then a check is performed every time a value is stored into an
annotated variable: the type of the value must be a subtype of the
annotated type.
Functions can be annotated too, in both their parameter and return
positions. Annotations on parameters constrain how the function can be
called. Annotations in the return position constrains what the function
can return:
function f(x: string): RegExp { ... }
There are two classes of types, nominal types and structural types.
Nominal types are introduced by class definitions and interface
definitions. Values of nominal types are created by instantiating
classes (using the "new" operator). The syntax and semantics are
broadly as in Java: A nominal type is equal only to itself; a value is
of a class type only if it was instantiated from that type; and it is of
an interface type only if it was instantiated from a class type that
declares that it implements that interface. (Note that the access
control keywords like private and public are actually aliases for
language-provided namespaces.)
Methods on classes appear as function definitions in the class body.
The class instance is in scope in the body of a method.
Structural types are record types (for example {x:int, y:i
RE: Adobe position paper on the ECMAScript 4 proposal space -- decimal
Hi Mike, taking your questions in order: Regarding "Premature" / "Knowledgable users" When we say decimal is "premature" we mean it in the sense outlined in the paper only: The TG had an intuition about what we wanted for the language (The Right Thing - essentially a type of big red switch) but then we came to the conclusion that what we wanted is simply not workable on the web (see below), and therefore we now no longer know exactly what it is that we want. Therefore decimal is premature in the sense we use here: more experience may be necessary before the TG members know what we want. As authors of the position paper, Jeff and I did not and do not mean to imply that decimal arithmetic, considered in isolation, is immature, far from it. About the big red switch. There are two variants: One is global to an execution context, were a program sets the global floating point mode to be decimal and all arithmetic is carried out in decimal (and all literals are decimal); the other is lexically scoped, where a "use decimal" pragma affects operators and literal interpretation in its lexical scope. (In either case the implementation will use a polymorphic number representation and perform most arithmetic on integers, of course, but on overflow the representation becomes decimal floating point rather than binary floating point if the switch has been turned on.) To take the global case first: Two of the themes that have been very prominent in the work of the TG have been that ES4 must support existing ES3 content exceptionally well, and that we must expect that most web sites that migrate to ES4 will not do so all at once, but will upgrade some of their code to ES4, leaving other code as unmodified ES3. For example, one could imagine a page that has exception handlers and some infrastructure code that are all ES3 code but which loads ES4 code dynamically if the browser supports ES4. Mashups are another example; in this case, the page author has no control over the code loaded into the page (and for a long time most of it will be ES3 code). As a third case, code on one page can call code on another page (or in a frame or iframe). In summary, the TG has considered it to be unacceptable to require a program to consist of all ES3 code or all ES4 code, mixing is going to be the reality. As a consequence of those compatibility concerns, it is unacceptable for one piece of code to alter the floating point environment of the other code by flipping the big red switch to "decimal", because the consequences of doing so are unknown. Of course decimal has a larger exponent range and higher precision than double-precision floating point; but my experience with ES on the web is that people write code with all sorts of dependencies, and many TG members believe that there is important code out there that depends on the number representation being "double". As a compromise it would be possible to make the big red switch apply only to ES4 code that runs in an all-ES4 environment, but my sense is that the browser vendors do not believe that is a particularly compelling use case (nor does Adobe). The lexically scoped case has other problems. On the one hand, the programmer controls when "1" means "decimal(1)" and when "a+b" means "decimal(a)+decimal(b)". On the other hand, the question is really how far this control extends. What happens when code in the context of "use decimal" reads a number from a data structure defined outside that scope, or receives a number from a function defined outside that scope -- is the number converted to decimal? What if the code stores a decimal value in an external data structure or passes it to an external function that expects a double? The issues of compatibility with existing ES3 code reappear in this context. Furthermore, the intent was also that the "use decimal" pragma should control the precision and rounding settings in a lexical fashion, but that precludes those settings being passed off implicitly to separately defined functions or library functions that (maybe!) should take them into account. Overall, the lexically scoped case has usability issues, and TG members (myself as much as anyone) were not convinced that they can be overcome at this time. More experience is needed. Maciej has already discussed performance concerns surrounding a general switch to decimal. Since a polymorphic number representation ensures that decimal is used only for floating-point numbers, any concerns should apply mainly to programs that perform a significant amount of floating-point arithmetic (programs that have a significant number of overflows from machine integer but which then chop values back to integer would be impacted too). I believe strongly that there are web applications out there that will see a significant slowdown, but I do not know how important the problem is in practice. Speaking for Adobe, current ActionScript code tends to use strong static typing and v
Re: Adobe position paper on the ECMAScript 4 proposal space -- decimal
Lars, many thanks for posting the interesting Adobe position paper. Could you explain a little more about your position on decimal support? In particular: Your description of the standardization of decimal arithmetic as 'premature': The requirement for adding decimal arithmetic to ECMAScript was raised in TC39 in October 1998. The notes of TC39 WG meetings show this was discussed in the meetings of 1998/11 and also of 1999/11. The final TC39 'futures' list shows decimal support as being on the very short list of 'provisionally agreed' items for ES4, as of 1999/03. In the meantime, the decimal arithmetic in the IEEE 754 revision (754r, now in ballot) has been widely adopted, with extensions being made to many languages, including ECMA C# and CLI, Java, ISO C, Python, and SAP ABAP, to better support it. A number of C compilers ? including GCC ? already have the new decimal support, and software libraries are available from several sources. Hardware support is now available in two server architectures: power.org's PowerPC (since June 2007) and IBM's z10 mainframes (announced yesterday). In short, decimal support in ECMAScript is overdue, not premature. The 'use decimal' notation means that only knowledgeable users will get to use it: This is a valid criticism. This approach is not ideal, but at least means that where decimal arithmetic is essential it is available easily. In contrast, it is currently not available at all; it is very hard to replicate server-side calculations on the client using binary floating-point. However, the 'big red switch' approach that you advocate would probably be better ? in essence saying that external environments can override the arithmetic base used within scripting if the scripting engine supports that. What approach would Adobe favor for this? There have been a number of suggestions (for example, in an HTML context a meta tag in the of a page could be used, which page builders could add by default for new pages). It is not necessary to define the mechanism for all hosting environments (and that is probably outside the scope of TG1 in any case). Your assertion that implementing decimal may be a hardship for implementations on smaller systems: Our current fixed-size decimal library, including all the 754r operations on both basic decimal formats (including FMA and many other functions and modes not needed for ECMAScript) are less than 80kBytes when compiled using GCC for Pentium. An ECMAScript implementation, using just one format, would probably need at most a third of this. Your assertion that implementing decimal may be a hardship for implementations that cannot use existing open-source libraries: There are now a number of open-source libraries implementing the 754r decimal types. At least two of these are essentially 'public domain' licenses. For example, ours is a part of the International Components for Unicode (ICU) library, whose license allows unrestricted use of source and derivative works in any project or product. The only requirement is acknowledgement of copyright. (For the full text of the license, which is just three paragraphs, see http://source.icu-project.org/repos/icu/icu/trunk/license.html .) We have had no requests or suggestions that would imply that the ICU license would prevent any implementation from using the library. The ICU libraries are widely used in many projects and products (including a number of Adobe products). Thanks ? Mike - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mike Cowlishaw, IBM Fellow IBM UK (MP8), PO Box 31, Birmingham Road, Warwick, CV34 5JL mailto:[EMAIL PROTECTED] -- http://www2.hursley.ibm.com/mfcsumm.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
