ES3.1: Draft 1

[Pratap Lakshman (VJ#SDK)]

I have uploaded to the wiki 
(link,
 see bottom of the page) a first draft of the specification for ES3.1. This is 
in the form of in-place edits and markups to the ES3 specification. As you will 
notice when reading through, there are still some open issues, and details on a 
few features to be filled in. This spec shall be updated as we make progress on 
these.

pratap

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: A random collection of ES4 draft spec surprises and thoughts

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark S. Miller
> Sent: 26. mai 2008 11:07
> To: es4-discuss@mozilla.org; [EMAIL PROTECTED] x-discuss
> Subject: A random collection of ES4 draft spec surprises and thoughts
> 
> In going over the ES4 draft spec docs, I found the following 
> things surprising:

Other people took care of everything except this one:

> * Is "A catch-all method operates on the object that contains 
> the method." a mistake? Did you mean "operates on the invoked object"?

My phrasing is clumsy, but in my universe we invoke functions and
methods, not objects, and I was trying to convey that sense of
reality.  The sentence does not end with a period but with a second
clause: ", not on that object's prototype object." and that's the
main point: the method only operates on the specific receiver object,
not on the receiver's prototypes.  But you're right to point out
that it could be improved.  Thanks.

--lars 
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Proposed ES4 draft 1

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> Sent: 17. mai 2008 03:07
> To: es4-discuss@mozilla.org
> Subject: Re: Proposed ES4 draft 1
> 
> 
> In core-language.pdf, "1.3.1 Property Binding Map", a paragraph reads:
> "A property binding map stores the order in which properties 
> are added to the map. A property's position in this order is 
> unchanged when the property is replaced. This order is used 
> by property enumeration (see the chapter on Statements)."
> 
> I just wish you make clear one detail here: Does removing and 
> adding a property with the same name change its enumeration 
> order, or is that equivalent to a replacement? I think it 
> probably should remove it from the enumeration order and 
> insert it at the end. 

I agree, and I think the spec needs to be clear on this.

> In core-language.pdf, "1.4.5 String Values", you allow both 
> ES3 compatible 16-bit UCS-2 code units and 32-bit Unicode 
> code points (and, I would assume, 21-bit code units which 
> would behave exactly as if they were UTF-32 code units).
> If an implementation is UTF-8 under the hood but leaves the 
> programmer-visible indexed access per either one of those 
> models (with notably worse algorithmical complexity for 
> random access but not for serial access), is that okay per the spec?

If it's under the hood it's out of the spec's jurisdiction,
but it's possible the spec could be clearer about that.  We'll
see.

> In core-language.pdf, "2.1 Catch-All Methods", the default 
> behaviour of accessing the value from a dynamic property in 
> the object's property map is mentioned. Is there a way for 
> non-default catch-alls to do this, too? (Maybe they only want 
> to treat a special subset of property names differently, not 
> all names...)

There is not.

> In core-language.pdf, "2.3 Reading a property value" the last 
> fixme reads:
> "FIXME We need to specify whether the bound method is cached 
> or not, ie, whether, given that o.m is a method, (o.m === o.m)."
> 
> Whether o.m is a method or not shouldn't change anything, should it?
> As long as it's just named and not called it's the same 
> object. If there's a setter or getter for that particular 
> name or a catch-all, now, that's where this issue arises.

You're assuming the conclusion.  The reason this is an interesting
question is that good implementations will not allocate function
objects for methods until they need to (at that point performing
an implicit 'bind' operation too, of course), and the question is
whether implementations will be required to cache these objects
when they do create them.  I think the sane thing to do is to
require lazily created objects to be cached; it simplifies the
language and the spec -- objects appear to "have" properties that
are bound methods -- even if it adds an additional burden to some 
implementations.

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Jeff Dyer]

On 5/27/08 8:45 AM, Maciej Stachowiak wrote:

>> Is the cost too high? I think that depends on how the name lookup
>> algorithm works on real-world code. AS3 developers have data to
>> share. Let's get into that.

You looking at me? ;-) I don't have that data, but I'll gladly see if I can
find some.

> 
> I'd love to hear the data. AS3 developers, can unqualified lookup of
> object properties on untyped references in the presence of property
> namespaces be as fast as when there aren't namespaces at all?

Seems unlikely since more work is being done.

> If so, how? The most obvious way to do property lookup when there is no
> static type info is a hashtable lookup on each prototype chain entry,
> but I do not see an obvious way that a single hashtable lookup can
> look in multiple namespaces. I suspect the answer to this in AS3 is
> that if you want performance, you have to use type declarations.

Some of the complexity in the name resolution algorithms is to ensure that
references to fixed properties cannot be shadowed. This means, with or
without static type information, references to fixtures need only be
resolved once. So the incremental cost that is incurred during unqualified
name lookup is amortized across multiple evaluations of the reference in
which it occurs. 

Other bits of complexity in those algorithms is there to disambiguate names
in the case of conflicts. It would be interesting to study how often this
code gets invoked in practice. It might not come into play all that often.

Jd

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 28, 2008, at 12:48 AM, Maciej Stachowiak wrote:

> On May 27, 2008, at 1:07 PM, Brendan Eich wrote:
>
>> I forgot one of the main use-case for 4, one you've expressed  
>> interest in already: 'use namespace intrinsic'. Without (4), this  
>> does not allow early binding for s.charAt(i) given var s:string to  
>> string.prototype.intrinsic::charAt.
>
> Yeah, but you can't early bind this anyway if s lacks a type  
> annotation (or you otherwise have inferred that s is of string  
> type). In fact if you can't infer the type of s then you get worse  
> performance than if you hadn't opened any namespaces.


That depends on the implementation, but let's say it's true. You  
still get the better-typed fixtures (the string class's  
intrinsic::charAt method) instead of possibly overridden prototype  
properties.

The 'use namespace intrinsic' design for early binding grew out of  
the "compact profile" of ES3, which is a dead letter on the web  
because it's overtly incompatible (the spec is short enough to read  
in a few minutes: http://www.ecma-international.org/publications/ 
standards/Ecma-327.htm). A pragma for prioritizing fixed methods with  
stricter type signatures was prototyped by the strict mode in AS3.  
During collaborative ES4 development in TC39 TG1, we synthesized  
aspects of these precursors into 'use namespace intrinsic'.

This design is implemented in the ES4 RI, and it will probably be in  
a couple of practical open source implementations this year. We want  
to get user as well as implementor feedback.


> But you do have my number - I like the potential for early binding  
> both for program understandability and performance. I would love to  
> see a way to make it possible without at the same time making  
> property lookup in the face of unknown types slower. I will think  
> about it myself but perhaps someone else will come up with  
> something clever.

Great. In the mean time, we'll be working on clever solutions to  
speed up all property lookups, even with open namespaces. Maybe we'll  
convince you that cleverness is better applied by implementors to  
enable programmers who benefit from new things like cross-cutting  
intrinsic, debugging, version2, etc. namespaces.


> As for my motherhood & apple pie lecture, it is based on experience  
> with a working on a high-performance production-quality JavaScript  
> implementation. We managed to pretty much rewrite the core  
> interpreter for a significant performance boost in about two  
> months, and that was struggling against the existing complexity of  
> de facto JavaScript (ES3 + some Mozilla extensions). Along the way  
> we found some correctness bugs that exist in pretty much all  
> existing implementations (sequencing considerations in the face of  
> exceptions for instance). If the language were much more complex,  
> then it would be much harder to make architectural changes of the  
> implementation.

Two months. Sorry, but if it took you three or four months to do that  
and also include namespace optimizations, but the benefit to the  
great many JS or would-be ES4 programmers were enough, then why  
wouldn't you take the extra month or three?

Given the needs of the many and the scale of the web, I continue to  
believe that the main argument should be about maximizing usable  
utility for programmers writing in the new version of the language --  
only secondarily about hardships for implementors who make the big  
bucks making JS go fast :-/.

/be


___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[liorean]

> On Wed, May 28, 2008 at 12:48 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>>> I want to say thanks for making this proposal (open namespace search only
>>> for lexical references). It leaves most of the use-cases I cited intact.
>>> Well done, good compromise (not complete evisceration of property
>>> qualifiers, or dismissal of unqualified import).

While I like the idea, it doesn't address at least two of the use
cases for namespaced properties:
- Having both a fully typed and an untyped version of the same method
on the object, allowing code to switch through just opening a
namespace if the programmer knows their code is type consistent.
- Allowing user classes or objects to present interfaces overriding
behaviour inherited from Object which were internal and unexposeed in
ES3.

The first point is mainly a convenience feature.

The second point can be addressed using new syntactic forms for each
such case. (If using the form "operator [no newlines here] ident",
that would be a safe way to do it since all code looking like that
cause a syntax error in ES3.) I don't know if that's a good or bad
idea though.
-- 
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Mark S. Miller]

On Wed, May 28, 2008 at 12:48 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>> I want to say thanks for making this proposal (open namespace search only
>> for lexical references). It leaves most of the use-cases I cited intact.
>> Well done, good compromise (not complete evisceration of property
>> qualifiers, or dismissal of unqualified import).
>
> Thank you for saying so. I wonder what Mark thinks?

Hi Maciej, I'm still absorbing, so I don't completely get it yet. But
I do like the direction a lot. It seems to be a big improvement.

> (For the record, I think
> open namespaces as affecting lexical scope only would also remove the need
> for first-class Name objects.)

Yes, this is the clearest sign of how big an improvement. Variable
lookup would once again be looking up a programmer-written identifier
in a lexical environment to get a location, as opposed to the draft
ES4 spec's double lookup (looking up an identifier to get a Name, and
then looking up a Name to get a location). IIUC, it moves the
complexity into the nature of the lexical environment handling the
lookup, but that's it. Do I have this right?

Frankly, I won't have time to look at it more today. Perhaps you could
do an informal presentation on it at the Thurs/Fri meetings coming up
in SF?

-- 
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Mike Shaver]

On Wed, May 28, 2008 at 2:46 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> I think it would be simpler to limit the effect of namespaces to lexical
> bindings (where we know we can bind to the right name and namespace
> statically in any case of interest) and not have them affect object property
> lookup in general.

OK, that would be simpler, though I do worry about breaking the
"window.whatever is the global whatever" model a bit for web
developers.  Thanks for the explanation.

Given that namespaced lookup is used on the scope chain, |with
(window)| would then do namespaced lookups, albeit perhaps more
slowly?  Does that also mean that |with (someobj)| will be a way to
get namespaced lookup on non-global objects?

Mike
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

On May 27, 2008, at 1:07 PM, Brendan Eich wrote:

> On May 27, 2008, at 11:42 AM, Maciej Stachowiak wrote:
>
>> On May 27, 2008, at 11:00 AM, Brendan Eich wrote:
>>> What's at issue is whether and why unqualified import matters in  
>>> any object, even the global object only, since the NAS proposal  
>>> did not allow unqualified import even at global level, and the use- 
>>> case for unqualified import was dismissed as not compelling.
>>
>> There's really 4 separable issues:
>>
>> 1) Namespacing of names at global scope (via lexically scoped  
>> reference).
>> 2) Unqualified import of names into global scope.
>> 3) Namespacing of arbitrary object properties.
>> 4) Unqualified import of namespaces for arbitrary object properties.
>>
>> I would claim 1 and 2 are essential, 3 can be done by convention in  
>> the absence of 4 (a la the NAS proposal) and 4 is unnecessary and  
>> harmful to performance.
>
>
> Thanks, this is helpful, since the argument you joined was about (2)  
> and/or (4) -- there is no unqualified import in the NAS sketch.
>
> I forgot one of the main use-case for 4, one you've expressed  
> interest in already: 'use namespace intrinsic'. Without (4), this  
> does not allow early binding for s.charAt(i) given var s:string to  
> string.prototype.intrinsic::charAt.

Yeah, but you can't early bind this anyway if s lacks a type  
annotation (or you otherwise have inferred that s is of string type).  
In fact if you can't infer the type of s then you get worse  
performance than if you hadn't opened any namespaces. Plus lookup of  
any property names that couldn't have been early bound at all if the  
exact type had been inferred is likely to suffer. So I'm not sure any  
more it is good to encourage adding "use namespace intrinsic" to  
otherwise unchanged ES3 programs.

But you do have my number - I like the potential for early binding  
both for program understandability and performance. I would love to  
see a way to make it possible without at the same time making property  
lookup in the face of unknown types slower. I will think about it  
myself but perhaps someone else will come up with something clever.

As for my motherhood & apple pie lecture, it is based on experience  
with a working on a high-performance production-quality JavaScript  
implementation. We managed to pretty much rewrite the core interpreter  
for a significant performance boost in about two months, and that was  
struggling against the existing complexity of de facto JavaScript (ES3  
+ some Mozilla extensions). Along the way we found some correctness  
bugs that exist in pretty much all existing implementations  
(sequencing considerations in the face of exceptions for instance). If  
the language were much more complex, then it would be much harder to  
make architectural changes of the implementation. I believe this is a  
quality worth preserving. Well-engineered tight code can sometimes  
beat the fanciest of rocket science optimizing implementations simply  
because it is easier to understand and therefore measure and optimize.

(To some extent, this applies less to pure syntactic sugar that can be  
represented in terms of core language constructs, which is why I worry  
more about complex semantics.)

> I want to say thanks for making this proposal (open namespace search  
> only for lexical references). It leaves most of the use-cases I  
> cited intact. Well done, good compromise (not complete evisceration  
> of property qualifiers, or dismissal of unqualified import).

Thank you for saying so. I wonder what Mark thinks? (For the record, I  
think open namespaces as affecting lexical scope only would also  
remove the need for first-class Name objects.)

> The helper/informative usage in the RI does open those namespaces,  
> and intrinsic works only as a cross-cutting namespace that can be  
> opened via pragma. So we should focus on these, if only to agree to  
> disagree on the importance of the former, argue for hardcoding the  
> latter via a separate early-binding pragma, and so forth.

I'm not sure there is a good design for an early binding pragma is   
that is immune to the performance costs. One possibility I can think  
of is to it an error to access a property by an early-bound name on an  
object that lacks the early-bound version when the pragma is in effect  
(without explicitly qualifying it as not subject to early binding).  
That seems potentially icky.

Regards,
Maciej

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss