Re: Argument matching
or relaxed On May 12, 2008, at 8:10 AM, Peter Hall wrote: Since both modes are to be specified by upcoming standards documents, can we adopt some term other than standard for the mode we'd like to discourage? I propose loose. I agree. But I think lenient sounds better. Peter ___ 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
Argument matching
What should ES4 do when there are too many or too few arguments?
Seems that the RI will apply different behavior depending on whether
the function arguments are typed or not. This is not necessarily
unexpected. I just want to nail down the rules as the RI and AS3
behave differently in this regard.
Consider:
function fun(a, b) {
print(a);
print(b);
}
Calling this with:
fun(1) prints
1
undefined
fun(1,2,3,4)prints
1
2
fun(1,undefined)
1
0
both work without error.
But if either arg is typed:
function fun(a: int, b) {
print(a);
print(b);
}
In this case, the following all get TypeErrors
fun(1)
fun(1, undefined)
fun(1,2,3,4)
Interestingly, ASC will coerce undefined to 0 if supplied with the
correct number of arguments and they are typed as ints.
What are the rules for ES4?
- If you type formal arguments, it seems the caller must supply the
correct number and type of actual parameters
- If you don't type the formal arguments, you can supply too few or
too many arguments
- Should undefined be coerced to 0 if the type is an integer?
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Argument matching
There is a problem with that. If it is an error to provide too many actual parameters to a function with typed formal parameters, then you either must supply the correct number of args or not type the args. A use case that demonstrates the problem is the Array.some callback. Usually it is supplied with only one argument -- the element. So if a user declares this callback with type annotations, the call will fail as the iterator must supply 3 arguments. So you can't have a callback with just one typed argument for the callback. You must either have one untyped arg or 3 typed arguments. Michael On May 9, 2008, at 10:58 AM, David Mandelin wrote: Lars Hansen wrote: I would expect excess arguments to typed functions to be ignored silently, as they can be picked up by 'arguments' inside the function. Is there any possibility of making whether a function takes extra arguments part of its type? It seems kind of unfortunate not to be able to report an error when too many args are given, which is a pretty common mistake and usually indicates a bug. Dave ___ 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: Argument matching
Comments below:
On May 9, 2008, at 10:43 AM, Lars Hansen wrote:
In strict code (use strict) the number of passed arguments must
match
the number of expected arguments. This has been agreed upon.
I presume that is at execution time?
I would expect that if too few arguments are passed to a function with
a typed interface then you get a type error unless the missing
parameter
has a type that includes undefined (ie no conversion takes place).
See comment in following email about Array.some callbacks.
Signalling an error because the function has a typed interface is
a variant, I guess, but it seems like an orthogonal concern.
I would expect excess arguments to typed functions to be ignored
silently,
as they can be picked up by 'arguments' inside the function.
I think this is the only approach that will work for standard mode code.
So for Array.some in strict mode, the user must supply 3 typed
arguments for the callback.
But in standard mode, they can either do that, or supply one untyped
arg.
I can't think of a better solution (yet).
Michael
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael O'Brien
Sent: 9. mai 2008 10:30
To: es4-discuss Discuss
Subject: Argument matching
What should ES4 do when there are too many or too few arguments?
Seems that the RI will apply different behavior depending on
whether the function arguments are typed or not. This is not
necessarily unexpected. I just want to nail down the rules as
the RI and AS3 behave differently in this regard.
Consider:
function fun(a, b) {
print(a);
print(b);
}
Calling this with:
fun(1) prints
1
undefined
fun(1,2,3,4) prints
1
2
fun(1,undefined)
1
0
both work without error.
But if either arg is typed:
function fun(a: int, b) {
print(a);
print(b);
}
In this case, the following all get TypeErrors
fun(1)
fun(1, undefined)
fun(1,2,3,4)
Interestingly, ASC will coerce undefined to 0 if supplied
with the correct number of arguments and they are typed as ints.
What are the rules for ES4?
- If you type formal arguments, it seems the caller must
supply the correct number and type of actual parameters
- If you don't type the formal arguments, you can supply too
few or too many arguments
- Should undefined be coerced to 0 if the type is an integer?
Michael
___
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: Argument matching
The tests below in the RI were in standard mode. So that is an RI bug.
Michael
On May 9, 2008, at 10:43 AM, Lars Hansen wrote:
In strict code (use strict) the number of passed arguments must
match
the number of expected arguments. This has been agreed upon.
I would expect that if too few arguments are passed to a function with
a typed interface then you get a type error unless the missing
parameter
has a type that includes undefined (ie no conversion takes place).
Signalling an error because the function has a typed interface is
a variant, I guess, but it seems like an orthogonal concern.
I would expect excess arguments to typed functions to be ignored
silently,
as they can be picked up by 'arguments' inside the function.
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael O'Brien
Sent: 9. mai 2008 10:30
To: es4-discuss Discuss
Subject: Argument matching
What should ES4 do when there are too many or too few arguments?
Seems that the RI will apply different behavior depending on
whether the function arguments are typed or not. This is not
necessarily unexpected. I just want to nail down the rules as
the RI and AS3 behave differently in this regard.
Consider:
function fun(a, b) {
print(a);
print(b);
}
Calling this with:
fun(1) prints
1
undefined
fun(1,2,3,4) prints
1
2
fun(1,undefined)
1
0
both work without error.
But if either arg is typed:
function fun(a: int, b) {
print(a);
print(b);
}
In this case, the following all get TypeErrors
fun(1)
fun(1, undefined)
fun(1,2,3,4)
Interestingly, ASC will coerce undefined to 0 if supplied
with the correct number of arguments and they are typed as ints.
What are the rules for ES4?
- If you type formal arguments, it seems the caller must
supply the correct number and type of actual parameters
- If you don't type the formal arguments, you can supply too
few or too many arguments
- Should undefined be coerced to 0 if the type is an integer?
Michael
___
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: Argument matching
I've only used named rest arguments
function f(obj, ...items)
I forgot you could do:
function f(obj, ...)
you're right - no overhead.
Another RI bug - that form won't work when you invoke it:
**ERROR** MachError: defining out-of-bounds temporary (near a.as:
5:4-5.3)
Michael
On May 9, 2008, at 12:00 PM, Lars Hansen wrote:
-Original Message-
From: Michael O'Brien [mailto:[EMAIL PROTECTED]
Sent: 9. mai 2008 11:49
To: Lars Hansen
Cc: es4-discuss Discuss
Subject: Re: Argument matching
Presumably what you're getting at is that if 'checker' is
strict then
it must accept three arguments even if we only care about
one. This
is so.
The easiest way to write down a function like that is to
use the rest
parameter without a parameter name:
function f(obj, ...) { /* code here */ }
Agree, but that may have a performance penalty as the extra
args must be converted to an array.
Why would they have to be converted to an array, if that array can't
be referenced? :)
One case where strict mode may be faster than standard ;-)
So that I can write up a bug for the RI, my take on the rules is:
- In strict mode, the number and types of args must agree. If
not, an error is generated.
- In standard mode, you can supply too many actual
parameters, they will be ignored. If you supply too few,
undefined will be automatically supplied for the missing args.
In my opinion, yes. But this has not been discussed extensively,
and not for a long time, so others may have different understanding.
Types must agree in standard mode too, of course (at run-time).
--lars
The RI exhibits strict behavior in this regard in standard mode.
Michael
On May 9, 2008, at 11:37 AM, Lars Hansen wrote:
-Original Message-
From: Michael O'Brien [mailto:[EMAIL PROTECTED]
Sent: 9. mai 2008 11:09
To: Lars Hansen
Cc: es4-discuss Discuss
Subject: Re: Argument matching
Comments below:
On May 9, 2008, at 10:43 AM, Lars Hansen wrote:
In strict code (use strict) the number of passed arguments must
match the number of expected arguments. This has been
agreed upon.
I presume that is at execution time?
It is.
So for Array.some in strict mode, the user must supply 3 typed
arguments
for the callback. But in standard mode, they can either
do that, or
supply
one untyped arg.
static function some(object:!Object, checker:Callable,
thisObj:Object=null): boolean {
for (let i=0, limit=object.length; i limit ; i++)
if (i in object)
if (checker.call(thisObj, object[i], i, object))
return true;
return false;
}
The type of 'checker' used to be Checker:
type Checker = function (*, double, Object):boolean;
but that is painful in practice. The intrinsic instance
method still
requires a Checker, though.
Presumably what you're getting at is that if 'checker' is
strict then
it must accept three arguments even if we only care about
one. This
is so.
The easiest way to write down a function like that is to
use the rest
parameter without a parameter name:
function f(obj, ...) { /* code here */ }
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RI Bug
The RI (latest build) skips a finally block due to a break in catch:
for (i = 0; i 10; i++) {
print(i)
try {
throw throwing
}
catch (e) {
print(Catching)
break
}
finally {
print(Finally)
}
print(Bottom)
}
print(After)
This prints:
0
Catching
After
Should print:
0
Catching
Finally
After
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Multiple declarations
Follow up: The RI allows typed redeclarations providing the type is not double. This works: // var x:double = 7 // delete x var x:boolean = true delete x var x:string = there delete x var x:boolean = false delete x var x = false delete x But uncomment the first declaration and you get: defining ... **ERROR** FixtureError: incompatible redefinition of fixture name: x (near t.as:1:1-1.3) I presume this is an RI bug? Michael On May 1, 2008, at 4:12 PM, Jeff Dyer wrote: Works for me in the RI: var x = 10; var x = 20; print(x) 20 As it should. Jd On 5/1/08 4:07 PM, Michael O'Brien wrote: Is the following valid? var x = 2 var x = 3 The ES4 RI prevents this. ASC redefines x. What should this do? Michael ___ 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: Multiple declarations
Thanks - a new build fixed it. Michael On May 1, 2008, at 4:14 PM, Graydon Hoare wrote: Jeff Dyer wrote: Works for me in the RI: var x = 10; var x = 20; print(x) 20 As it should. Could be an old build? Check one of the snapshots. http://buildbot.ecmascript.org/es4/waterfall -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Class static blocks
I wanted to clarify the meaning of a static block. Consider:
class Shape {
static var count
var origin
static {
// Is this static initialization code?
count = 1
}
{
// Is this instance initialization code?
origin = 0
}
}
Reading the latest draft of the grammar I'm assuming that you must now
put static init code inside a static {} block. Is this correct?
Does that mean that other directives outside of methods and static
blocks are instance initialization code? If so, does it run before or
after the constructor code?
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Order of initialization
I'm unsure how the class level initialization code should run:
Consider:
class Circle extends Shape {
print(Circle)
}
class Shape {
print(Shape)
}
The RI and ASC currently bomb on this due to the forward class
reference, however, my understanding is that this is perfectly legal.
Now should the Circle initialization code run first because it is
first in the file, or should Shape run first because it is a base class.
Should we see
Circle
Shape
or
Shape
Circle
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Declarations
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
What happens in the RI is the class declaration seems to occur where
it is coded. It is not being
hoisted to the top of the enclosing var block. Whereas the function
declaration is and thus can
be called before its declaration.
Is this an RI bug or just a divergence from AS3?
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Declarations
Jon, thanks. Any thoughts on the original post?
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
What happens in the RI is the class declaration seems to occur where
it is coded. It is not being
hoisted to the top of the enclosing var block. Whereas the function
declaration is and thus can
be called before its declaration.
Is this an RI bug or just a divergence from AS3?
Michael
___
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: Declarations
Here is a confusing example that bears it out.
var x = 1
print(x: + x)
var y = Shape.z
print(y: + y)
class Shape {
public static var z = x
print(z: + z)
}
Currently es4 (and ejs) print:
x: 1
y: undefined
z: 1
ASC prints:
z: undefined
x: 1
y: undefined
NOTE: both values and order of execution are different.
I prefer the current es4 behavior because static class initialization
code can predictably
use lexically scoped values. And it behaves like var declarations.
Michael O'Brien
On Apr 15, 2008, at 12:13 PM, Lars Hansen wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael O'Brien
Sent: 15. april 2008 15:06
To: Jeff Dyer
Cc: es4-discuss Discuss; Jon Zeppieri
Subject: Re: Declarations
Jeff,
Can I tease out a bit more detail. I'm not sure I agree with
what the correct answer should be.
Lars raised the issue with var a while back and I think, if
my memory serves me, the conclusion was that the variable
should be hoisted to the top of the var block, but the
initialization statement should execute in place.
ie.
= declaration for y hoisted to here
print(y) // Y should exist here but be null
x = 1
var y = x// Assigment from x remains here
If the above is true for variables, should we not have the
same rules
for functions and for
classes? ie. shouldn't class static initialization code
remain inline
where the class is defined?
I'd recommend that we make var,function and class all behave
the same
way.
They don't work the same way, in ES3.
IMO method init needs to be hoisted in classes like function
init is in ES3. I think this is important for implementations
with vtables.
Classes are compile-time entities (with types and namespaces)
and may need to be privileged that way, in initialization terms.
More later.
--lars
Does any of the above change if enclosed in a package block?
I presume
the class declaration should
be hoisted to the top of the package block. But still, the
initialization remain inline where the
class was declared.
Michael
On Apr 15, 2008, at 11:58 AM, Jeff Dyer wrote:
This is an RI bug too (my fault). AS3 initializes programs in a
single pass,
before evaluating the top level code. The RI does both in
one pass.
I just
filed a bug (http://bugs.ecmascript.org/ticket/382)
Jd
On 4/15/08 11:38 AM, Michael O'Brien wrote:
Jon, thanks. Any thoughts on the original post?
Question about declarations:
Consider:
print(Shape.x)
public class Shape { public static var x = 1; }
print(Shape.x)
fun()
function fun() { print(fun); }
In the RI this prints:
undefined
1
fun
In ASC this prints:
1
1
fun
What happens in the RI is the class declaration seems to occur
where
it is coded. It is not being
hoisted to the top of the enclosing var block. Whereas the
function
declaration is and thus can
be called before its declaration.
Is this an RI bug or just a divergence from AS3?
Michael
___
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
___
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: let* is the new var
We define the slots for vars and functions first at the top of the block
and do initializations in-order where they reside in the code flow. So:
class XX {
function foo ...
// fooAlias exists here but is undefined
var fooAlias = foo
// fooAlias is now initialized
}
Michael
On Apr 2, 2008, at 2:49 PM, Lars Hansen wrote:
Don't remember this ever coming up; I always assumed it would be like
for ES3 code (scopes of names are the entire block; functions are
initialized first; then variables in order).
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of P T Withington
Sent: 26. mars 2008 05:48
To: Dave Herman
Cc: es4-discuss Discuss; Jon Zeppieri
Subject: Re: let* is the new var
This conversation makes me ask, what is the semantics of var
in a class declaration? E.g.:
class ... {
function foo ...
var fooAlias = foo;
var bar = 42;
var bletch = bar + 1;
etc.
Same rules? All slots created at the top of the block and
initializations executed in order? I'm particularly
interested in the case of creating an alias to a function.
On 2008-03-25, at 19:03 EDT, Dave Herman wrote:
Created as ticket #375:
http://bugs.ecmascript.org/ticket/375
Dave
___
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
___
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: Any discussion of compact subset for mobile devices?
On Mar 20, 2008, at 10:56 PM, ToolmakerSteve98 wrote: Lars Hansen wrote: but several companies that participate in the ES4 work are planning to ship on small devices. And they have been participating in the work in part to make sure that's possible. I am very glad to hear that you are pressing for that. Anyhow, subsets are pretty pointless on the public web. An implementation that wants to play needs to support the full language. That's what concerns me. To my mind, the next step in logic execution for the web should be strongly biased to favor low power low memory devices. We want complex application logic running on client devices. ALL client devices. Looking at all the technical approaches that have been tried, what would give the most bang for the buck? After a rough look at the size of the language grammar and spec, and perusing some of the past mail discussions about subtleties in parsing/analyzing certain constructs -- WHOA - this is stuff we take for granted on our multi-GHz and GB desktop PCs today, but ES4 would web-standardize a language that would require every web client to take on that burden. My gut reaction is that Microsoft has taken a better tack: let this stuff be resolved at authoring time down to a CLR. Don't burden every web client device with it. We are doing exactly that in our implementation. It is only a subset of ES4 currently, but does many of the big pieces including classes, static typing, namespaces, packages, units, most of the grammar, type annotations, conversions, strict and standard mode. The online spreadsheet tracks progress pretty well. We are using an off-device compile phase and then running a VM on device to execute pre-compiled byte code. We are running this on standard feature phones using a C based and a java based VM. Our footprint is 200K to startup. I expect that when we have all the language that this number will go up to ~350K. We do provide compilation directives to allow OEMs to deselect features that are not required in their device. This results in a non-standard OEM implementation, but compatibility with the web is not a concern. So while we have a long way to go to be compliant and fully featured, I am confident that ES4 can run on very modest devices with acceptable performance. That's why I ask about compact subset. I'm initially skeptical that what I'm seeing is the right next step for the web. But I think there are a lot of good ideas here, so I'm working through it, looking for common ground between stuff I see at Microsoft and stuff I see here. So I'm against defining a compact subset standard. The reason is that everyone wants a different subset and defining a hobbled edition won't meet anyones needs. I'd rather have one standard and then provide a mechanism for those who must defeature the language to select the portions required. This does prevent interoperability of programs, but it does strengthen the integrity of what is ES4. Michael O'Brien ~TMSteve ___ 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: Any discussion of compact subset for mobile devices?
This may be a little off topic for this group, so lets continue this offline after this. The ES4 spec is being written to not preclude off-device compilation. After all, that is what AS3 does very well. So both approaches 1) all- in-one compile/execution and 2) pre-compile then execute later are possible and desirable in different situations. In our case, sometimes the compilation happens at the development phase. In other cases it happens hosted at the server and can be tailored based on the phone features and capabilities. The former being simpler, the latter being more comprehensive. Michael On Mar 21, 2008, at 12:12 AM, ToolmakerSteve98 wrote: We typically don't need to query the device to select language features. Michael, I think you've missed my main point. You are using an off- device compile phase. THAT'S the feature I was talking about. I'm trying to understand how that fits into public web compliance. If the answer is that you have enough control over the situation to intercede between the phone and the web, then I totally get it. Not a solution I had thought of, but works for me. Is that approach agreeable to all the cell phone carriers? (If not, then I'm back to my original are you sure this is practical? gut reaction.) ~TMSteve ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: server-side ECMAScript 4?
We will be using our ES4 implementation server side. Mainly for embedded uses, but it could apply more broadly. We have a server side page technology like ASP -- called ESP. This simply processes % code % sequences and effectively converts the web page into javascript code that is then processed. We've used this in our Appweb embedded web server for quite a while, but the javascript language was very limited. Still it has worked well. Upgrading to ES4 will give a very sweet server side environment. Of course, we have had to add quite a bit of extra library code suitable for server side processing. What kind of server side were you interested in? Michael O'Brien Mbedthis Software On Mar 8, 2008, at 3:14 PM, ToolmakerSteve98 wrote: Are there any Open Source projects to develop server-side ECMAScript 4? I'm in preliminary stages of locating (or starting if none exists) a project to use Tamarin/ActionScript 3 on both server and client. This would naturally evolve into ES4 once that is final. Researching to see what exists. My tentative thought is to adapt Whitebeam http://www.whitebeam.org/ from SpiderMonkey to Tamarin. This would provide an XML-based Web Application Server. Targeting Flash Player 9 on the client side, as a rich media platform. (and Flash Lite 2 on mobile devices -- looking forward to a future version with AS3 support). If anyone has an interest, or any relevant information, please let me know. ~ToolmakerSteve [EMAIL PROTECTED] http://toolmakersteve.com ___ 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: New Operator
I'll vote for that also. It improves readability quite a bit. But is there a better operator than "\"? Shame "//" is taken. What about "/." Michael Lars Hansen wrote: I have been pushing for this in the past on several occasions, but enthusiasm in the WG has been scant, unfortunately. Maybe I haven't been pushing hard enough. --lars From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of TNO Sent: 5. mars 2008 14:13 To: es4-discuss@mozilla.org Subject: New Operator Is it too late to propose an integer division operator into the spec? I do quite a bit of WSH programming in both _vbscript_ an JScript and sometimes its a bit of an irritant during a translation, it would be nice to see this operator "\" available in the new ECMAScript instead of having to rely on more inefficient workarounds: _vbscript_: Dim result result = 19 \ 4 '(result = 4) JScript: http://www.codingforums.com/showthread.php?t=58799 ___ 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: implementation dependencies (was Re: ES4 work)
What about the actual content sections? We want the same look and feel over the text -- what perspectives do you need covered in describing a feature. Do you have a sample? Michael Graydon Hoare wrote: Brendan Eich wrote: I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? You missed this question above. No, I ducked :-). Lars is editor with Jeff assisting and (as always) maintaining the grammar; I would appreciate Graydon's thoughts too. *Shrug* I'm not picky. I think Lars has been working more in HTML, and that's what I hope most of the spec-writing will happen in, just because it's real easy to render, edit, version control and such. But plaintext or some flavour of wikitext is also convenient. Word docs less so, though I think they're the final target form ECMA wants. And of course there are our more academic members who feel more at home in LaTeX. Whatever floats your boat. It's relatively easy to interconvert, either way. -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Seems to me we may have some emerging agreement on the following items. Please be kind if I'm overstating the consensus, but I believe the following items start us in the right direction without being too onerous. Triage the existing proposals into those that are current and correct and those that aren't. Publish that list. Bring the out-of-date proposal pages up to date Implementers designers pitch in and write up design notes for proposals. This is then both input to the spec and immediate guidance for implementers. Some doc/comments for the RI Create a common place to store resolutions and clarifications on issues. The mailing list isn't great for this gems get lost in the volume. Perhaps the author for each design note could maintain the document and append questions on the end as clarifications in wiki style. I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? Michael ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Comments below: This sounds good, but if we've accepted proposals and need detailed specs, why not write specs? This is not just a matter of wiki namespace (proposal: vs. spec:). Proposals have emphasized precedents, use-cases, and anti-use-cases, and considered alternatives. Discussion uncovered further detail, but still not enough for a spec in all cases. The reason is we could remove a few road blocks with some design notes. These won't be as complete as the spec but could from the basis of writing some of the spec prose. Also, the spec can reference the RI (not just SML but, for the standard library, the self-hosted ES4!) in a systematic way. Proposals preceded the RI. The problem here is time. I think doing the spec with the required level of rigour will take much longer than would be ideal to get implementations started. Suggest we evaluate Lars's forthcoming library spec and see what proposals pages it effectively updates. Agree we should mark those pages somehow as superseded by specs, with links to the specs. Not thrilled about leaving out-of-date proposals around, but there's clearly a conflict between the wiki, which is great for content creation, and the trac and spec, which are better for disposition and finalizable specification. I've seen an early cut of the Library spec. Is an update coming? Again I am leery of reinventing the RI in prose, duplicating its meaning with added bugs and no testability. Better to refer to the RI directly as I think you proposed earlier, or even excerpt it as was planned for the spec. The ES4 excerpts should not need lowering; Graydon's script can be used if people find SML hard to read. Fine to refer to the RI, but I think we're talking notes here. Graydon's emails contain a lot of good notes but are certainly not a spec (yet). I think we just need more of those notes. I would agree that if this can't be done simply and easily, we should just push on as forward momentum will eventually deliver the goods. Time is never a friend if we are slow or meandering. Create a common place to store resolutions and clarifications on issues. The mailing list isn't great for this gems get lost in the volume. Perhaps the author for each design note could maintain the document and append questions on the end as clarifications in wiki style. Tracking issues is a job for the trac, although there's always room for on-the-side summaries linking to tickets, if you keep editing to keep up with the primary source of truth in the trac. I think the summaries are where the gold is. That is the piece we are missing. We actually have a lot of information, but it is scattered and hard to put together in a coherent manner. I'll start the ball rolling with writing up some notes on Program Units, use unit and unit dependencies. Brendan/Jeff: what format would you like these notes in? You missed this question above. Cheers Michael ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 work
Graydon, Thanks -- that helps to understand the status. You are in a somewhat unique position having implemented more than any other. Given Jeff's roadmap outline and the goal of weighing the features against implementation experience -- which of the features that you have implemented do you feel were difficult, costly or problematic? In our implementation (Ejscript), we have implemented (with bugs): - classes - namespaces, including use pragmas - block scope - packages - units - pragmas - let, const, let-const - type expressions / definitions / annotations - runtime type checks (standard mode) - destructuring assignment - hashcode - meta objects - strict mode (incomplete checking) - type parameters - numbers decimal - getters setters Namespaces was a much bigger and more intrusive change that I first anticipated. Difficult to get it to perform well, but we're still working on it. However, once byte-code is generated for bound code, there is no cost. Similarly, block scope added considerable complexity. Program units were fairly straight forward as is strict mode and pragmas. Structural types and type checking is next on our high priority list. Michael Graydon Hoare wrote: Michael O'Brien wrote: Could Graydon give a snapshot of what is not implemented in the RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful. Sure. I can describe the state of most issues as named by the proposals page, I think. Some of the proposals have sort of no-longer-sensible names so I'm going to use the proposals page as a rough guide and name the things that have seemed, in my work, to be separate features of the RI. Implemented, may have bugs: - classes and interfaces - namespaces - pragmas - let, const, let-const - iterators - enumerability control - type expressions / definitions / annotations - runtime type checks (standard mode) - nullability - destructuring assignment - slice syntax - hashcode - catchalls - map vector - date time improvements - meta objects - static generics - string trim - typeof - globals - expression closures - name objects - type operators (is / to / cast / wrap) Implemented and partly working, but still in flux / work to do: - inheritance checking - strict mode - type parameters - structural types - numbers decimal - getters setters (structural part is incomplete) - packages Partially implemented / not yet working: - program units - generic function - updates to unicode - updates to regexps Unimplemented: - generators - tail calls - triple quotes - stack inspection - reformed with - resurrected eval (eval exists but may be wrong) - help for the argument object - this function / this generator In my mind the high priority deficits where I actually know what to do are: - extending strict mode - extending the part of the definer that checks inheritance The remaining issues on my list all involve some spec/discussion work (units and packages, type parameters, structural typechecks, tail calls, reformed rules for with/this/eval/arguments) -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: implementation dependencies (was Re: ES4 work)
Comments below: Going further, I have mentally considered the language as providing 3 big categories of enhancement: fixtures, types, and namespaces. I think that within -- and possibly between -- these groups there are dependencies. For example, we can consider these levels of type-implementation: TY-VAL: a runtime representation of types exists, and values have a pointer to their type TY-PROP: properties can be annotated with types, and a dynamic check is made when an assignment is made TY-DEF: type-aliases (type T = ...) can be defined TY-STRUCT: the full structural type grammar exists (object types, array types, function types) TY-NULL: the nullability extension to the type grammar exists TY-NOMINAL: class and interface types exist, with a hard-coded subtype lattice TY-PARAM: the parametric type system exists TY-LIKE: the 'like' types exist TY-STRICT: approximate static checking of types TY-REFLECT: meta-objects exist and can be acquired with typeof This is a partial dependency list. You need at least TY-VAL to do TY-PROP, but it's probably possible to implement any combination of the remainder once you're at TY-PROP. You could also stop *at* TY-PROP, only permitting users to denote the ES3 types (prims and objs). Though IMO this would be silly. We began and have a fairly complete TY_VAL and TY_PROP. Next we did TY_NOMINAL and TY_REFLECT. We are missing DEF, STRUCT, NULL, PARAM and LIKE. We have partial STRICT. We can also consider levels of namespace-implementation: NS-VAL: a runtime type namespace exists, and has some nonempty population NS-PROP: every property has a namespace and namespace references can be used in reference expressions like obj.ns::prop and ns::lexref NS-USE: the use namespace and use default namespace pragmas automatically qualify definitions or references NS-DEF: namespace declarations are accepted and new namespaces can be defined through them, either anonymous or with strings NS-CLS: classes (and interfaces?) define their own namespaces for conventional OO visibility control NS-PKG: the package construct exists for automatically defining namespaces Similarly, this list is more linear at the top than the bottom: NS-PROP and NS-USE require NS-VAL, though one could stop there with (perhaps) a fixed population of namespaces. The remaining 3 are mostly orthogonal: you could for example stop implementing with NS-DEF and ignore classes and packages, and still have a useful system. Or do NS-CLS alone and ignore NS-DEF, using namespaces only to model class-visibility issues. I think this is very much an all or nothing. It is hard to separate out these from each other. We started with NS_DEF, NS_VAL and NS_PROP. NS_USE was easy NS_USE is pretty easy once you have NS_VAL and NS_PROP. NS_PKG is essential if you are going to handle package qualified variables and avoid name collisions. So I'd imagine it would be hard to have a cohesive whole without doing all these items. All the type and namespace issues depend, however, on fixtures. We are some ways towards proving that fixtures-in-absence-of-namespaces are equivalent to the dontdelete property attribute (see ticket #233, http://bugs.ecmascript.org/ticket/233) but if you have namespaces there appears to be a requirement to be modeling fixtures, to run the multiname algorithm properly. Fixtures are sort of super-dontdelete properties -- those that can safely be early bound, in addition to not being deletable -- and it's hard to make much use of the namespace or type systems without them. Agree. We had fixtures first and retrofitted namespace (which I would not recommend). Namespaces are so foundational, you need to design them in at the start. Otherwise, there is a lot of rework. Re-encoding the ES3 primitives as classes, and the new classes like map, vector and the meta objects, all require a fair amount of the TY and NS work: at least TY-NOMINAL, TY-PARAM and NS-CLS (I think). Looking at the builtins, I can't imagine how you could do them without namespaces. They are a vital solution to various name lookup and collision problems. Finally there is a category I left off the above elaboration, mostly because it is under-developed in the RI: control mechanisms. There are dependencies between tail calls, generators and stack inspection, and I can't say I fully understand the dependencies nor the impact they have on the rest of the implementation. There are a whole raft of implementation toughies that will vary a bit from implementation to implementation. We have spent a lot of time trying to get ES4 to be small and fast. But there is a long, long way to go. Michael -Graydon ___
Re: ES4 work
. 2. The RI is a key implementation too. In your work flow, the RI seems to lag the implementations and you say it has a role in prototyping features. But it has been filling a crucial role in clarifying what the proposal was really meant to do. This goes beyond prototyping. I regard the RI as the first implementation and the last. The first, in the sense that it should define how the features are meant to function and guide implementers and prevent many blind alleys. The last in the sense, that it defines the spec. I'd like to stress that it must continue to lead in implementing all key features. Admittedly I was doing a little hand waving here. Clearly the RI has given us early insight into the language design, forced issues to the surface sooner rather than later, and given us a model to play with. And in terms of feature scope, the RI is fairly complete (thanks mostly to Graydon). The point of the workflow is to show when key milestones are reached. In this end game plan, here really isnt a clear and useful milestone associated with the initial implementation in the RI. We could define one but that might just add unnecessary overhead to the process. I see the current RI as a part of that bundle of materials we call Proposals. Could Graydon give a snapshot of what is not implemented in the RI in terms of the proposals / features? I know the trac database lists all, but a punch list of the high priority deficits would be helpful. Your timeline below does not indicate the kind of implementation readiness you need to make this work flow actually work. Can you detail what kind of implementation feedback you need? Two questions come to mind: 1 do you understand the feature well enough to write a detailed specification of it? 2 are you willing to ship it as is (modulo bug fixes and performance tuning)? For #2, we are quite happy to risk shipping features prior to standardization and we will do our very best to adapt, change and track the standard. We are pretty up front with users on this front. Regarding #1, I may not possess the skill to write specifications. My skills are more as an implementer than a language designer and even less as a writer. I find that I pale when compared to other more leading lights in this regard. Lastly, please don't interpret the above 2 issues as negative feedback. I think this is a good and normal process for defining a spec. We need to have real-world experience using these features to prevent painful errors going forward. Thanks, no offense taken. On the contrary, I see the advanced ES4 implementation work you have done as a great asset that we need to leverage. The process outlined here can be used by those with shared values and vision to produce a strong specification that defines the language of multiple implementations. It needs further refinement, but mostly it just needs to be done. Your welcome. We are looking forward to releasing our first snapshot soon. Michael Jd On 2/15/08 11:20 PM, Michael O'Brien wrote: Jeff, Thanks for outlining the process to go forward. Overall I like having real implementations prove the value and feasibility of features and proposals before they are poured in concrete. But I see 2 2 obstacles that I outline below: 1. What actually are the proposals? Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do. I've been using the RI, Lars's paper and emailed questions to flesh out my understanding of the proposals -- but my understanding is often incomplete or inaccurate. So my question is what are the agreed set of proposals and where are they adequately documented? A related question that exacerbates this problem is what has become of the discussion to trim / streamline some of the feature set. As implementers, we don't want to spend time implementing features that are not likely to be in the final spec. 2. The RI is a key implementation too. In your work flow, the RI seems to lag the implementations and you say it has a role in prototyping features. But it has been filling a crucial role in clarifying what the proposal was really meant to do. This goes beyond prototyping. I regard the RI as the first implementation and the last. The first, in the sense that it should define how the features are meant to function and guide implementers and prevent many blind alleys. The last in the sense, that it defines the spec. I'd like
Re: ES4 work
Jeff, Thanks for outlining the process to go forward. Overall I like having real implementations prove the value and feasibility of features and proposals before they are poured in concrete. But I see 2 2 obstacles that I outline below: 1. What actually are the proposals? Many of those proposals on the Wiki are dated and much water has gone under the bridge on these proposals since they were first made. Many conversations have been had with sometimes subtle and sometimes not so subtle changes to the meaning of those proposals. This presents a real problem for implementers in understanding exactly what has been proposed and what is the meaning of the proposals. For those who were present in those conversations and meetings may have it all committed to memory, but those who have not present will certainly struggle to gain a clear and exact understanding, as I do. I've been using the RI, Lars's paper and emailed questions to flesh out my understanding of the proposals -- but my understanding is often incomplete or inaccurate. So my question is what are the agreed set of proposals and where are they adequately documented? A related question that exacerbates this problem is what has become of the discussion to trim / streamline some of the feature set. As implementers, we don't want to spend time implementing features that are not likely to be in the final spec. 2. The RI is a key implementation too. In your work flow, the RI seems to lag the implementations and you say it has a role in prototyping features. But it has been filling a crucial role in clarifying what the proposal was really meant to do. This goes beyond prototyping. I regard the RI as the first implementation and the last. The first, in the sense that it should define how the features are meant to function and guide implementers and prevent many blind alleys. The last in the sense, that it defines the spec. I'd like to stress that it must continue to lead in implementing all key features. Your timeline below does not indicate the kind of implementation readiness you need to make this work flow actually work. Can you detail what kind of implementation feedback you need? Lastly, please don't interpret the above 2 issues as negative feedback. I think this is a good and normal process for defining a spec. We need to have real-world experience using these features to prevent painful errors going forward. thanks Michael O'Brien Mbedthis Software Jeff Dyer wrote: Hi, We have entered a new phase in the development of the ES4 standard. Since September we have had a fixed set of proposals to consider individually and as a whole. The final step is to translate those proposals into production implementations and to document the language that results to become the next ES standard. What follows is a high level description of the process that we (Adobe and Mozilla) feel should be followed to get from Proposals to a high quality, finished specification. We should discuss this at our ES4-WG phone call this Tuesday (Feb-19). Advanced comments welcomed. WORKFLOW The basic workflow: Proposal -- Implementation -- Feature spec -- Feature review -- ES4-RI -- ES4 spec -- Proposal - see http://wiki.ecmascript.org/doku.php?id=proposals:proposals. These proposals are the pool of possible feature proposals. Only exceptional circumstances will warrant a feature not covered by an accepted proposal to be considered. Implementation - interested implementers collaborate on the implementation of a feature described by the proposals. This exercise should end with one or more implementations of the feature to provide feedback on usability and implementation complexity. Feature spec - one of the participants from the implementation team writes up a description of the feature based on that implementation. Feature specs are complete and accurate descriptions of individual features to be added to the language. They are supported by production implementation, test cases and implementer commitment to release the feature. Feature review - ES4-WG reviews the feature spec and implementation and when satisfied accepts the spec to be included in the ES4 spec. ES4-RI - once accepted, the RI is checked for compatibility with the production implementation and readability. Although the RI is used as a kind of prototype of the proposals, its primary purpose is aide in understanding and exposition of the language. This step involves preparing parts of the RI for inclusion in the spec. ES4 spec - and finally, the ES4 draft is updated to include the accepted feature and reviewed first by ES4-WG and then TC39. IMPLEMENTATION TEAMS The implementation teams will be ad hoc collaborations between two or more implementers. Ideally, at least one of those implementers is an Ecma member so that the feature has representation throughout the standardization process. ES4-WG AND TC39 MEETINGS The ES4-WG
Scope rules
I'm trying to find the scope rules for constructor initializers and for
function parameter default values. If someone could point me to a
document or clarify these that would be great.
I've read bits and pieces. For constructor initializers:
class Shape {
function Shape():
leftSide = rightSide
{
}
function render(arg1 = expression) {
}
}
In the constructor initializers, I presume the leftSide has a scope
equal to just outside the constructor and the rightSide binds to inside
the constructor. Is this right?
Also, can this be used in either right or left side?
For function default arguments, is the scope of the expression just
outside the function?
Michael
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Extracting getters and setters
Question about getters and setters. Can you assign a getter / setter to
a var and invoke later? i.e. can you extract a getter/setter method?
Consider:
class Shape {
function get width(): int {
return 1;
}
function set width(value: int): void {
}
/* Does this assign the getter or setter */
var fun = width
}
var s: Shape = new Shape
s.fun()
ASC will extract the getter. But what should ES4 do? How can you extract
the getter or the setter or both?
Under the hood, is the width getter/setter to be stored as one property
or 2 and what is the property name?
Thanks
Michael O'Brien
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
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: Global functions
While this compiles in the RI, it still produces 2 and 2 for the output.
ie. doesn't seem they are block scoped functions either.
Michael
John Resig wrote:
I was under the impression that for the function definitions to be confined
to a block scope, you had to define them as such (with let function
statements), like so:
package {
{
let function fun() {
print(1);
}
fun()
}
{
let function fun() {
print(2)
}
fun()
}
}
I'm unsure if this currently works in the RI, or not.
--John
- Original Message -
From: Michael O'Brien [EMAIL PROTECTED]
To: es4-discuss es4-discuss@mozilla.org
Sent: Thursday, December 13, 2007 7:10:41 PM (GMT-0500) America/New_York
Subject: Global functions
Are global functions declared with block or global scope. ie. declared
in the block object or var object?
Consider:
package {
{
function fun() {
print(1);
}
fun()
}
{
function fun() {
print(2)
}
fun()
}
}
This prints
2
2
in the RI.
So should functions be treated like var declarations or as let
declarations. Seems like they are like vars in the RI.
Is this right?
Michael O'Brien
___
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: 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: Namespaces
Thanks - that explains both questions.
We've got this working pretty smoothly now. If as Graydon pointed out
we allow pragmas to be placed
anywhere in a block, the whole mechanism becomes much easier to use.
Rules about where you can and
can't put directives makes the language harder to predict and use.
Michael
Jeff Dyer wrote:
On 12/12/07 11:13 AM, Michael O'Brien wrote:
I've got a question about how user defined namespaces should resolve
inside of packages. This is really an ES4 implementation question and
not a usage question.
Consider:
package one {
public namespace blue = "http://blue"
}
package one {
use namespace blue
blue var x :int
}
package two {
public namespace blue = "http://blue"
}
package two {
use default namespace blue
blue var x : string
}
This fails to compile as the two "blue var x" declarations have
different fixture types. So this implies that variable declarations
inside packages that have namespaces with identical URI = are not
defined with any package qualification. ie. the namespace is the only
qualification. This is what I expected, but just
wanted to confirm this.
That is correct. A namespace attribute in a package body overrides the
default package qualifier. AS3 allowed only public and internal at this
level, but we have agreed that we would allow such use of namespaces inside
of packages and interfaces. #335 just opened to clarify.
Also, I noticed in the RI that you can't have namespace (and other)
declarations outside of a "package {" block. ie.
namespace blue
package {
}
will fail to compile, but put the namespace declaration inside of
"package {" and it works. Surely, these declarations should be allowed
outside an explict package declaration due to the fact that there is an
implicit "package {" around global declarations?
The error probably has to do with the fact that the current grammar requires
packages to be defined at the top of a compilation unit. It is our intention
to change this letting package definitions to be interspersed with other
definitions and statements.
Jd
Michael O'Brien
___
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: need some clarification on compile-time type vs. run-time type
Brendan,
I didn't see the reflect namespace documented in the overview.
Can you please provide some pointers to its doc?
Michael
Brendan Eich wrote:
On Nov 9, 2007, at 5:29 PM, Yuh-Ruey Chen wrote:
The confusion I'm getting is that there seems to be many ways to check
or differentiate between types. For example, consider the following
ES3
function:
function foo(x, t) {
if (!(x instanceof t))
throw some_type_error;
print(x);
}
If t were a fixed type property, then foo could be redefined as:
function foo.t(x) {
if (!(x is t))
throw some_type_error;
print(x);
}
Here t is the name of a type parameter to foo, so it is by definition
fixed -- it doesn't matter how you instantiate foo.T for some T --
but there again, in the foo.T _expression_, you need a fixed type
term T.
Or maybe the following is possible (it's currently disallowed in
the RI):
function foo.t(x: t) {
print(x);
}
I'll let Graydon reply in full, and give an update -- I heard he
nearly has type params working.
Which one is preferred in ES4? The ES3 version is more flexible in a
way, since it treats types as first-class values,
A constructor function is not a type in ES1-3, it's a function
object, which if user-defined has a completely writable prototype
property that instanceof checks. So it is not bad (or good), but I'm
here to say: it's not about types in the ES4 sense.
Indeed user-defined constructor functions all make Object instances,
by definition, although you could strengthen them to make structural
subtypes of Object in ES4:
function MyConstructor(a, b) {
return {a: a, b: b} : {a: int, b: string};
}
but the last version
is the most efficient. Users will have to deal with this choice,
but it
requires a decent understanding of the type system to make a good
choice.
Users can buy by the yard. The old ways work for the dynamic
constructor/prototype world everyone knows.
Above you have made three different things. The instanceof check is
not the same as the |is| check. The type paramter example is yet
again different -- it's just printing x assuming x is compatible with
t -- that is, that there's no type error on attempt to call foo.T,
e.g. foo.Date(new RegExp).
And it doesn't end there. I haven't even addressed the |is like|
compound operator,
It's not a compound operator: 'like' is a type constructor or type
unary operator if you prefer: like T is a type, you can use it
freely. Thus because (x is T) can be tested, and T can be defined as
like U, you can write (x is like U). Make sense?
of which there is no counterpart in |instanceof|
since structural types apparently can't be stored as non-fixed type
properties (|type x={a:int};y=x;| doesn't work in the RI).
Type are types, not functions; the instanceof right operand is a
*function* per ES1-3 and backward compatibility.
I'm not sure how to phrase this, but it seems to me that ES4 is trying
to make fixed properties and non-fixed properties (and by extension,
type expressions and value expressions, and compile-time features and
run-time features) as similar and compatible as possible (e.g. |10 is
int| and |10 instanceof int|), yet there are evidently many cases
where
they can't be interchanged (e.g. my first example).
I think you are mixing up fixed and non-fixed properties with types
and functions.
I know from
experience that the more similar concepts get, the higher the
potential
for confusion, until they become the one and the same. And the two
concepts in question here cannot be one and the same if we want ES4 to
support efficient compilation. Perhaps, to reduce the confusion, the
differences between the two can be more pronounced, either through
syntax and/or behavior. I don't have any specific suggestions though.
Here's what should work:
10 is int = true
10 instanceof int = true
type T = int
10 is T = true
10 instanceof T = true
No confusion, so far (IIRC the RI has a bug on the last line, but
let's assume it is fixed). Now:
let U = int
10 instanceof U = true
10 is U = error
Using a const (or let const) does not help here, only type will do.
At the very least, the differences and similarities need to be
fully and
carefully documented. ES3 already has plenty of gotchas, and ES4 seems
to be introducing plenty more.
It's true that ES4 is introducing optional types. But remember,
they're optiona. You don't have to use them, but if you choose to,
you need to follow the rules about using type definitions or
equivalent (class, interface) to make bindings that are fixed typenames.
One escape hatch is to use reflection, which looks something like
{
use namespace reflect
print(typeOf(10).isSubtypeOf(U))
}
That's not working for me in the RI, and I may have misremembered a
Re: Language Size (was Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM)
If you come at this (like I first did) thinking of Packages as
containers, things can get confusing.
The secret to understanding is to start with namespaces, which are
central and critical to ES4 and backwards compatibility. I won't try to
describe namespaces here and will leave that to others far more
competent than me, but given namespaces, then packages are really just
a syntax shortcut for namespaces.
Now you could (as we did), overload the package name as the file name
of compiled program elements. However, this has restrictions and
complications. It starts burdening package names with meaning you
really don't want. Imports directives then become program unit
dependencies also.
Unit directives provide an independent naming for how various
components of a program will be bundled. Often these do not lie along
package or namespace boundaries. Units also provide dependency
information.
We use units directives to group program elements and name them as
external (pre-compiled) byte code files. In our case, we use the
UnitName as the name of the byte code file. We currently don't use the
unit URL. The compiler also has the option to merge all units and
dependent units into a single output file. Each unit file can thus have
code from one or more packages. Determining the units for an
application thus become a loading and network consideration.
So the unit proposal gives flexibility in deciding what program
elements should be loaded or transmitted as a unit. This is often
independent of and at cross purposes to package or namespace naming.
Michael
Our compiler uses the UnitName of the unit directive to name compiled
byte code files.
Brendan Eich wrote:
On Oct 31, 2007, at 3:46 AM, Maciej Stachowiak wrote:
I notice some seemingly duplicate
features that will perhaps become
more clear on closer reading of the spec.
For instance I see all three
of namespace, package and unit
productions in the grammar. With my
limited imagination it's hard to think of
how those could be three
interestingly different features.
What's the Sesame Street song? "... one of these things is not
like the other, one of these things just doesn't belong."
You are not alone in wondering about these three -- this has
come up at past TG1 meetings and we went ahead and implemented to get
experience. Michael O'Brien has a small-device implementation that he's
posted about here. He may have useful feedback.
This may help separate namespaces and units:
* A namespace is a qualifier on property name (a string in
general in ES1-3). It's a prefix to apply to unqualified identifiers
used by a block in which a 'use namespace N' pragma occurs at the top.
There are sane rules about ordering and ambiguity errors, covered
briefly in the overview. As you can see from the RI, namespaces are
used heavily. One benefit is to avoid incompatible name pollution of
unqualified identifiers in the standard objects and the global object.
* Aprogram
unitis an explicit reflection of the Program production's
semantics from ES1-3. When you see a program unit body's closing brace,
the steps in ES3 Chapter 10.2, plus ES4 steps like those, kick in. You
can nest units, and a server framework can expand them server side when
they are stated without bodies, but with locators that point to the
body in question. This preserves accurate source coordinates for errors
coming from nested units, and avoids downloading too many small files.
See the proposal for more detail.
These two are genuinely different, orthogonal, and useful
things, I think.
* Packages are built on namespaces, and unlike program units
they are open-ended. You can keep adding to a package (someone correct
me if I'm wrong), by writing
package acme.widgets {
...
}
several times in a row. As the overview notes, a package has two
namespaces, package-public and package-internal. There's an import
directive for pulling some or all of the public names of a package into
another scope.
/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: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
Totally agree that ES4 can be implemented without undue bloat. ES4 VMs should remain small with modest growth despite the features being considered for ES4. We too are creating a compliant ES4 implementation to serve embedded devices. So our target is not so much browsers, but small embedded devices including mobile. Typical uses are mobile widget engines and embedded web servers. Our implementation (EJScript to add yet another name) is dual license: open source and commercial as are our previous embedded projects. You won't see much on our web about this yet -- working too hard to complete our Alpha ;-), but we have both a Java and C VM running the majority of the ES4 language already including most of the big items: classes, packages, units, type annotations and have been using it in some commercial products already. So we are field testing ES4 features as we go. Our all up target memory footprint is 250K for a minimal script. We are currently on target although we are missing some of the runtime library. We have a split compile / VM design so this does not include the compiler footprint. We have found that some of the ES4 features are essential for us to get such a small base footprint. The improved typing greatly enhances early binding and helps allows byte code sizes to be reduced. Now if you have large programs and large object counts -- memory will go up of course. I would STRONGLY urge that those who have concerns about the ES4 spec, engage and try writing some code with ES4. The features blend well and the end result is a nice expressive language that keeps the old ES3 dynamism but adds powerful constructs for safer, more scalable programs. It seems to wear well the more you use it. It also works well incrementally where you can start with ES3 and selectively employ ES4 features as you wish. Michael O'Brien Steven Johnson wrote: The suggestions of bloat and instability from some corners are rather disingenuous when you consider that (1) at least one high-quality ES4 engine (Tamarin) will be available with a source license compatible with both open-source and commercial vendors, so the claim that it will be hard for browser vendors to implement can theoretically be reduced to a claim that it will be hard for browser vendors to integrate. (Sure, there may be technical or political obstacles to using a particular engine, but assuming that the ES4 spec will require every browser vendor to write their own implementation is clearly false.) (2) at least two active contributors to Tamarin (Adobe and Mozilla) have a very high vested interest in keeping code size small, as the success of both Flash Player and Firefox are predicated on acceptable download sizes. As Tom pointed out, the compiler for ES4 will definitely get more complex, but the VM is unlikely to grow significantly in size or complexity. ___ 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-discuss Digest, Vol 8, Issue 44
Doug, Yes, I think the time has come to table the ES3+ materials. It has been discussed on and off since April. Do you have something that describes this proposal in a material way? How can people evaluate ES4 vs ES3+ if ES3+ is unknown and unspecified? Michael Yehuda Katz wrote: Doug, What specifically would you do in ES3+ to improve this situation? -- Yehuda On 10/30/07, Douglas Crockford [EMAIL PROTECTED] wrote: Brenden is also correct:If the working group voted and the current proposal won - it is better to have a stronger, more secure language. Sure they can argue it is bloated, but SO WHAT? The proposal is not a more secure language. It does nothing to address ECMAScript's biggestdesign flaw: the insecurity caused its dependence on a global object. XSS attacks are a direct consequence of this flaw. By making the language more complex, this problem becomes even harder to reason about and fix. I have been bringing this up since my first day in the working group. This is not a concern that is being sprung at the last minute. The working group hasn't voted. The proposal has not won. We have agreed to disagree, developing two competing proposals in the same working group. I am pursuing with Microsoft a counter proposal for a simpler, reliable remedy to real problems. My position isn't that _javascript_ doesn't need fixing. I think we need to be more selective in how we fix it. Bloat, in my view, is not good design. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- Yehuda Katz Web Developer | Procore Technologies (ph)718.877.1325 ___ 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: is ES4 getting too bloated?
I may be able to add some input and some experience implementing ES4. We have chosen to implement the ES4 language creating a compiler and 2 VMs one in C and one in Java. We started with a partial implementation of ES3 which did support a small subset of ES3 with classes but no VM design and a very limited library. We currently have most of the ES4 language implemented and running. While it has been hard (what challenging programming enterprise worth the effort is not difficult!), I think the language actually wears better once implemented and used, compared to trying to write a spec - which is awfully difficult. I agree the ES4 language is somewhat large and complex. The compatibility constraints with ES3 certainly take a toll in terms of freedom of change and expression. However, we've found that implementing the whole language is quite feasible in a relatively short amount of time with a reasonably small team. We started about 12 months ago and have implemented most of the language with a very small team and budget. We expect to be complete Q1 next year. Like any language, you can use the features to write incomprehensible code, but you can also use the features to write very readable, maintainable and more safe code than was ever possible with ES3. While I started with concerns like you have voiced, the more I use the language, the more I like it. What we've experienced is that while the spec may seem complicated, implementation is often more elegant than the spec may seem to predict. This is not criticism of the spec and I certainly have very high praise for the TG1 team, but we've found that while some of the spec may seem complex, actual usage is often very intuitive. Furthermore, for implementers, there is great leverage of some features across the entire language. For example: adding namespaces, packages, units, block scope and prototypes may seem quite a mouthful to express in the spec -- for implementers, there is an elegant design in all this and once you have the basics of namespaces and block scope you can more easily implement many language features such as getter/setters by using those facilities. Lastly, as an implementer, having access to the technical materials: grammar, wiki and most importantly the reference implementation and test suite, has been invaluable and greatly accelerated our efforts. Michael O'Brien Yuh-Ruey Chen wrote: Hey all, I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex. I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large. Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5? -Yuh-Ruey Chen ___ 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 Grammar
Jeff, Thanks - that update seems like it has moved on in quite a few areas. A follow on question: My question is what is the use case for a NamespaceAttribute being a PrimaryName. ie. Identifier "." Identifier ... Given that Global NamespaceAttributes are defined to be: public internal intrinsic PrimaryName This allows Paths in the namespace attribute. e.g. the following are legal where debug and release are suitably defined. debug var x a.b.c.release var x My question is what is the use case for a NamespaceAttribute being a PrimaryName. ie. Identifier "." Identifier ... And how does one create such a "a.b.c.release"? Are namespaces scoped to packages and thus the "a.b.c" refers to a package like "org.mozilla.release"? Or are these runtime namespaces where release is a property of "c" in the above example? Or is the grammar incorrect? Thanks Michael Jeff Dyer wrote: Hi Michael, You might have an old cached copy of grammar.pdf. The first two issues were resolved in a previous version. I had a pending fix to the third issue. I made NamespaceAttribute a PrimaryName. That way you can use namespace qualified references as a namespace attribute. I've posted the latest and greatest, dated 14-oct-2007. Thanks, Jd On 10/14/07 11:25 AM, Michael O'Brien wrote: This is probably for Jeff, but I'll send to the list anyway. I was doing a scrub through the latest posted grammar and may have a few small edits. 1. QualifiedNameIdentifier includes the tokens "*" and OverloadedOperator. However, overloaded operator includes "*" also. Is the "*' token therefore multiply resolved? 2. AttributeIdentifier in PrimaryExpression (production 110) should be AttributeName 3. The production on 414 under NamespaceAttribute has: Path . Identifier Identifier But Path already encompasses this. So you can replace these two lines with just "Path" Same in productions on lines 417+418 Let me know if I have any of this wrong. Cheers Michael O'Brien ___ 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
