RE: Namespaces as Sugar (was: complexity tax)

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
> Sent: 29. mai 2008 13:49
> To: Mark S. Miller; Maciej Stachowiak
> Cc: es4-discuss@mozilla.org es4-discuss; Mark Miller; Douglas 
> Crockford
> Subject: Re: Namespaces as Sugar (was: complexity tax)
...
> We've since decided not to return Name instances from 
> for-in's underlying iterator -- that is, non-public-qualified 
> property identifiers are not enumerated. The motivation for 
> obj[name] and the reflection APIs remains strong in ES4.

It's a little more subtle than that, as the underlying iterator
returns only public names (as strings) by default, but it is
possible to feed the iterator constructor a set of namespaces,
and if that is done then it will return Name objects for all
the enumerable properties whose namespace is among the ones
fed to the iterator constructor.

The reflection interface will have something similar but that
design is far from finished.

--lars
___
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 8:25 AM, Mark S. Miller wrote:

>> (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).

Just for the record, Name objects arise in the reflection API in ES4,  
and they came up originally via the combination of for-in loop  
enumeration and namespaced property identifiers. So:

for (let name in obj)
   print(obj[name]);

should work given:

let obj = {ns::prop: 42};

and name will be bound to a Name instance with qualifier ns and  
identifier "prop". The disclosure of Name instances via for-in  
implies the ability to compute a property name by indexing an object  
with a Name instance (the disclosed instance).

We've since decided not to return Name instances from for-in's  
underlying iterator -- that is, non-public-qualified property  
identifiers are not enumerated. The motivation for obj[name] and the  
reflection APIs remains strong in ES4.

/be

___
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

Re: Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

On May 27, 2008, at 12:18 PM, Mike Shaver wrote:

> 2008/5/27 Maciej Stachowiak <[EMAIL PROTECTED]>:
>> It could save a lot of complexity, by not requiring any first-class  
>> support
>> for namespace lookup on arbitrary objects.
>
> Is the expectation then that having two lookup models, one for global
> objects and the other for non-global objects, going to provide less
> complexity?

My proposal is that there is one for lexical scope lookup along the  
scope chain (which considers open namespaces when binding unqualified  
names) and another for property lookup qualified to an object  
reference (which does not). Yes, I believe this will provide less  
complexity, because the scope chain and prototype chain algorithms are  
quite complex in the current proposal and not the same as each other.  
My rough proposal would greatly simplify the prototype chain algorithm  
and not make the scope chain algorithm any more complex (it may become  
simpler).

> In a browser, "window" is the global object; would property lookup on
> "window" be namespaced when referenced as such?  When you have a
> handle to another window?  When you use |this.prop| in a global
> function?

My proposed answer to all of these would be no.

> If we have namespace-aware lookup, it seems to me that it would be
> less complex for implementors and script authors alike for it to
> always apply, rather than just for one magical object.

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.

Regards,
Maciej

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

Re: Namespaces as Sugar (was: complexity tax)

[Graydon Hoare]

Brendan Eich 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).

Likewise. It's an important distinction to have made and I'm glad you 
made it. Gives the discussion clearer texture. I'm mostly sitting out 
the argument here, but there are good points being raised and it's good 
to explore around them.

> 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.

Deploying a 'use namespace intrinsic' pragma does more than give 
early-binding opportunity to ES3 code (which, realistically, you'll need 
to do some extra type-level work to fully resolve).  More importantly, 
it grants a one-switch migration point from mutable prototype slots 
(compatible) to fixed class slots (predictable). IOW it's a semantic, 
program-integrity feature.

This is IMO the more serious issue we're missing in the discussion. I 
want to elaborate on it here for the sake of clarity. What we have now 
is the ability to take ES3 code such as:

var x = "hello";
x.split("e");

and, by putting "use namespace intrinsic" at the front of it, make a 
rather drastic upgrade in its "integrity" (by at least some measure, see 
below). The call x.split() changes from a prototype-resolved lookup on a 
dynamic property (likely to resolve at String.prototype.public::split()) 
to a lookup that stops with the fixture intrinsic::split() defined on 
the class __ES4__::string, that x is an instance of. This fixture has 
the following "improved" nature:

   - It has fixed semantics! the user knows what they're getting and
 no 3rd party code twiddling String.prototype will change it.

   - It so happens that we "improved" the semantics by sticking dynamic
 typechecks on the boundaries of intrinsic::split(), so you'll get
 more type-error checking.

   - It can be cached and reused w/o worrying about cache invalidation
 due to mutation of String.prototype. The implementation can get
 adequate performance without having to play as-subtle tricks.

Moreover, a single "use namespace intrinsic" will upgrade an *entire* 
compilation unit at a time (or a limited scope within one) using this 
technique, without having to go through and modify every x.split() to 
x.improved_split().

I'd be curious to hear if there's another well-developed way to provide 
this sort of thing. I guess it could be done by some sort of pragma that 
is specific to the standard library, but the current technique will work 
for helping other library authors (dojo / yui / etc.) provide an 
integrity-upgrading facility for *their* users too. It'd be nice to make 
this technique usable to all.

(The same technique can be used to e.g. provide debugging-heavy variants 
of methods, or side-by-side usable "new" versions in the presence of 
"old" versions, that you toggle by opening namespaces. I have less 
experience with this, but IIRC it was part of Waldemar's the initial 
motivation.)

-Graydon

___
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 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. So you can't add one pragma and  
realize speedups or better type signatures for built-in methods. All  
you can do is access global intrinsic::foo bindings, which (in ES4,  
where opt-in versioning gets you immutable Object, Array, String,  
etc. without needing to open intrinsic) are few and not likely to  
realize a speed-up or more precise typing.

So early binding via namespacing would be gone. It could be  
reintroduced via an ad-hoc pragma. But that takes up complexity  
budget in the spec and real implementations too.


> It could save a lot of complexity, by not requiring any first-class  
> support for namespace lookup on arbitrary objects.

If I understand your proposal, meta::get or iterator::get could still  
be defined in an arbitrary object, and called with full qualification.


>> Lexical context, no dynamic open-namespaces scope.
>
> Note I said "compile to" so I think this was clear.

Just dotting an i, especially for everyone following along at home :-).

>> * internal namespace per compilation unit for information hiding  
>> -- hardcode as a special case?
>
> I'm not sure how this applies to unqualified import of namespaces  
> on arbitrary object properties.

Per the spec, internal is open in a separate set on the list of open  
namespaces. You don't have to qualify references to internal::foo.


>> * iterator and meta hooks in objects. Ugly __get__, etc., names  
>> instead?
>
> Unqualified import is not necessary for iterator or meta hooks.  
> Namespaces by convention (or __decoratedNames__) would be enough.

Agreed :-).


>> * helper_foo() and informative_bar() in the RI?
>
> I don't think any language feature should exist solely for the  
> convenience of the RI.

It's not just the RI. Namespacing for informative purposes in the RI  
is good programming style, akin to using helper namespaces in C++  
where top-level (but often class-level as you can see from reading RI  
builtins/*.es). `grep 'use namespace ' builtins/*.es` runs to 41 lines.


> If more effort must be spent the necessary complexity of the  
> language just to preserve current levels of performance,

No, to increase the levels of performance for the current version of  
the language. That's the horse going over the first hill from the barn.

Adding namespaces to the next major version could slip into the  
optimization frameworks under way in a couple of engines I know of.  
But you may doubt. That's ok. I maintain that the high order bit  
should not be the cost to implementors, rather utility vs. complexity  
facing users.


> then that takes away resources from implementing unnecessary  
> complexity to improve performance beyond current levels.

Or harmonizes with the "unnecessary" complexity that implementors  
trying to compete already face. Let's not prejudge the ability of  
competing implementations to (a) speed up; (b) optimize namespace  
search for common code. The first target has to be the programmer  
using the language, not the implementor. This does not mean  
implementor concerns do not matter, as I keep trying to reassure you  
-- only that they come second.


> In general, keeping the language simpler is good for performance.

Yet focusing on performance can complicate the language for  
programmers. It certainly has for other languages.


> Other things being equal, simpler implementations are easier to  
> change, and have more room to add complexity for optimization  
> without becoming too complex for human understanding.
>
> I will agree that some added language features are essential but I  
> think minor improvements in expressiveness that have large  
> complexity cost are a poor tradeoff.

Hard to disagree without more details. This is motherhood and apple  
pie stuff.


>> This is a good

Re: Namespaces as Sugar (was: complexity tax)

[ihab . awad]

Delurk to ask a question --

On Tue, May 27, 2008 at 12:18 PM, Mike Shaver <[EMAIL PROTECTED]> wrote:
> In a browser, "window" is the global object; would property lookup on
> "window" be namespaced when referenced as such?  When you have a
> handle to another window?  When you use |this.prop| in a global
> function?

What is wrong with the following strawman syntax: Define a form --

  import into  values ;

which puts all the values .* into . This can be
explained in terms of two first class objects,  and
. Now the global case is just a matter of defining an alias
for the global , in case it is not mentionable by a given JS
environment. Like maybe --

  import values ;

The remainder of the asymmetry, where the global lexical scope is
addressable as an object yet nested scopes are not mentionable as
first-class objects, is endemic to JavaScript and perhaps not a valid
topic of debate or change at this point.

This seems to solve the problem for module linkage, yet does not
introduce complexities in general purpose object key lookup. It can be
modeled simply as an addition of (possibly "virtual") keys to an
object. And it (correctly) requires the client to have write access to
the .

The problem occurs if you wish to fail "late" in case two namespaces
define the same name. This is where the keys can be virtualized so
that, at lookup time, an error occurs if a name is ambiguous. Yet this
is still localized to one first-class object resolving string keys to
first-class object values, which is well within the simple programmer
model of existing JS.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Namespaces as Sugar (was: complexity tax)

[Mike Shaver]

2008/5/27 Maciej Stachowiak <[EMAIL PROTECTED]>:
> It could save a lot of complexity, by not requiring any first-class support
> for namespace lookup on arbitrary objects.

Is the expectation then that having two lookup models, one for global
objects and the other for non-global objects, going to provide less
complexity?

In a browser, "window" is the global object; would property lookup on
"window" be namespaced when referenced as such?  When you have a
handle to another window?  When you use |this.prop| in a global
function?

If we have namespace-aware lookup, it seems to me that it would be
less complex for implementors and script authors alike for it to
always apply, rather than just for one magical object.

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 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.


That's an interesting idea, although we use namespace  
qualification along the prototype chain all over the place in ES4,  
and for what seem like good reasons.


Other languages with successful namespacing features don't have  
such a mechanism, so I am dubious of the goodness of these ideas. I  
am concerned that the namespace lookup algorithm for object  
property access is too complicated.


Agreed, this is the big issue. I share your concern, but the  
conservative approach (esp. with reference to C++) of throwing out  
non-global open namespaces looks like an overreaction, and it may  
not save much complexity.


It could save a lot of complexity, by not requiring any first-class  
support for namespace lookup on arbitrary objects.


It makes object property lookup depend on the set of open  
namespaces, which means obj.property may compile to entirely  
different code depending on the context,


Lexical context, no dynamic open-namespaces scope.


Note I said "compile to" so I think this was clear.



and it seems likely it will slow down property lookup when multiple  
namespaces are open but static type info is missing.


It certainly could, although we think not in implementations under  
way. Opening multiple namespaces without is not free in a dynamic  
language.


Is the name lookup algorithm much simpler if namespaces are top- 
level only? Since obj.prop could end up with obj referring to the  
(or I should write "a") global object, I don't see it. Unless you're  
proposing outlawing such object references using the namespaces open  
at top-level when obj is the global object.


I would propose that unqualified import only affects lexically scoped  
lookups, not object property access, even if the object in question is  
the global object. In particular, if you are willing to say  
"global.property" instead of "property", it is not such a hardship to  
say "global.ns::property".



If the only real justification is that it's a nice generalization,  
then I do not think it is worth the performance hit.


The nice generalization followed from particular use-cases, it did  
not precede them. I cited those cases (briefly). How about being  
responsive to them?


I think many (perhaps all) of those cases either use namespaces  
gratuitously or work fine without unqualified import (and so could use  
namespaces by convention). For example it doesn't seem important to  
allow unqualified import of the meta namespace.





ES (any version) has objects as scopes, as well as prototypes.  
It's hard to keep the gander -- objects below the top level, or on  
the prototype chain -- from wanting the same sauce that the goose  
-- the global object -- is trying to hog all to itself.


Is it really? Is there any other language where namespacing of the  
global namespace has led to namespacing at the sub-object level? C+ 
+, Java and Python all get by fine without namespacing of  
individual object properties.


C++ and Java are not the right paradigms for JS/ES. Python is  
better, but Python *does* allow import in local scope.


Python allows import from inside a local namespace, but does it allow  
import from outside a local namespace to affect lookup into that  
namespace? I am not aware of such a feature but I'm not a Python expert.




The reason namespacing at top level is essential to programming in  
the large is that the global namespace is a shared resource and  
must be partitioned in controlled ways to avoid collision in a  
large system. But I do not see how this argument applies to classes  
or objects.


See Mark's big post, which discusses (in item (b)) extending  
objects, including standard ones.


Saying the global object is a shared resource that must be  
partitioned, etc., but no others reachable from it, particularly  
class objects, are shared resources, is begging the question: what  
makes any object a shared resource? That the global is the only  
necessarily shared object does not reduce the benefit, or make the  
cost prohibitive, of sharing other objects reachable from it.


The benefit is less, because you can use separate objects in different  
namespaces instead of a shared object with namespaces inside it. The  
cost is great

Re: Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 27, 2008, at 8:45 AM, Maciej Stachowiak wrote:

I don't see how any of this argues for namespacing of properties on  
non-global objects, or why that case in particular requires  
unqualified import.


The topic was any single object, so if these are good for the global  
object, they may (not must) be good for other objects. That's the  
general (uniformity) argument, made further below (I'm hoping for a  
response).




One can certainly question the need for any namespacing of object
properties, let alone unqualified import of namespaces for such
purposes.


I hope so. I'd rather have someone question unqualified import  
than implicitly dismiss it, which is what seems to be happening.


I don't see how your statement is responsive.


Hey, I was agreeing with you (Mr. Assistant District Attorney Sir :- 
P). Questioning is fine.


What was "responsive" about your non-sequitur "One can certainly  
question the need ..." anyway? No one objects to asking clear  
questions that are not of the "when did you stop beating your wife"  
kind.


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.



Namespacing of non-object properties is poorly justified, in my  
opinion. Unqualified import of top-level names is well-justified. I  
don't see why you keep mixing the two together.


Sure you do, below where I gave particulars that led to the  
generalized namespace scheme in ES4.




but does not mean namespaces need to generalize beyond the global
scope. For example, global unqualified namespace import could  
desugar
(logically) into the injection of scope chain items instead of  
into a

general property lookup mechanism.


That's an interesting idea, although we use namespace  
qualification along the prototype chain all over the place in ES4,  
and for what seem like good reasons.


Other languages with successful namespacing features don't have  
such a mechanism, so I am dubious of the goodness of these ideas. I  
am concerned that the namespace lookup algorithm for object  
property access is too complicated.


Agreed, this is the big issue. I share your concern, but the  
conservative approach (esp. with reference to C++) of throwing out  
non-global open namespaces looks like an overreaction, and it may not  
save much complexity.



It makes object property lookup depend on the set of open  
namespaces, which means obj.property may compile to entirely  
different code depending on the context,


Lexical context, no dynamic open-namespaces scope.


and it seems likely it will slow down property lookup when multiple  
namespaces are open but static type info is missing.


It certainly could, although we think not in implementations under  
way. Opening multiple namespaces without is not free in a dynamic  
language.


Is the name lookup algorithm much simpler if namespaces are top-level  
only? Since obj.prop could end up with obj referring to the (or I  
should write "a") global object, I don't see it. Unless you're  
proposing outlawing such object references using the namespaces open  
at top-level when obj is the global object.



If the only real justification is that it's a nice generalization,  
then I do not think it is worth the performance hit.


The nice generalization followed from particular use-cases, it did  
not precede them. I cited those cases (briefly). How about being  
responsive to them?



ES (any version) has objects as scopes, as well as prototypes.  
It's hard to keep the gander -- objects below the top level, or on  
the prototype chain -- from wanting the same sauce that the goose  
-- the global object -- is trying to hog all to itself.


Is it really? Is there any other language where namespacing of the  
global namespace has led to namespacing at the sub-object level? C+ 
+, Java and Python all get by fine without namespacing of  
individual object properties.


C++ and Java are not the right paradigms for JS/ES. Python is better,  
but Python *does* allow import in local scope.



The reason namespacing at top level is essential to programming in  
the large is that the global namespace is a shared resource and  
must be partitioned in controlled ways to avoid collision in a  
large system. But I do not see how this argument applies to classes  
or objects.


See Mark's big post, which discusses (in item (b)) extending objects,  
including standard ones.


Saying the global object is a shared resource that must be  
partitioned, etc., but no others reachable from it, particularly  
class objects, are shared resources, is begging the question: what  
makes any object a shared resource? That the global is the only  
necessarily shared object does not reduce the benefit, or make the  
cost prohibitive, of sharing other objects reachable from it.


Prototype (the 

Re: Namespaces as Sugar (was: complexity tax)

[Erik Arvidsson]

On Tue, May 27, 2008 at 07:32, Mark S. Miller <[EMAIL PROTECTED]> wrote:
> Yes, agreed. Namespaces-as-Sugar (hereafter NAS) is too big for ES3.1.
> Perhaps it's too small for ES4. Again, it is simply my attempt to
> explain what I meant by "A language with some of ES4's syntactic
> conveniences but without ES4's semantics." I would be less happy with
> NAS added to a language than with nothing added -- the problem it
> addresses is a problem more in theory than in practice. The real
> problem in practice is module linkage. Dojo and YUI show that this is
> already adequately solved with patterns and libraries, with no new
> language mechanism needed.

This is the second time I hear you say that the namespace pattern used
by dojo and YUI is already adequate.  Let me debunk that myth.  Dojo
flattened their namespaces from things like dojo.foo.bar.baz to
dojo.baz since the ES3 namespace pattern is too vefrbose and painful
to use.  YUI people also complain that writing YAHOO.foo is painful
(all caps is hard to type).

Unqualified import of global objects is a must for programming at large.

I agree with Maciej here, if we can simplify the name lookup
significantly be removing unqualified import of property names then I
think we should do that.  That being said, having namespaced
properties seems useful and I'd rather have that if it can be made to
perform well as well as be made simpler to understand.

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

Re: complexity tax

[Mark S. Miller]

On Tue, May 20, 2008 at 7:02 AM, Mark S. Miller <[EMAIL PROTECTED]> wrote:
> 2008/5/19 Brendan Eich <[EMAIL PROTECTED]>:
>> On May 19, 2008, at 6:54 PM, Mark Miller wrote:
>>
>>> If I could
>>> have a language with some of the syntactic conveniences of ES4 but
>>> without ES4's semantics, I'd be quite happy.
>>
>> What semantics in particular, can you pick on something specific that's not
>> in your classes as sugar proposal (rather than have me guess)?
>
> Good suggestion. Will do. Top of my list will be first-class Name objects.


I have now read the three draft ES4 spec docs Lars sent out. Yes, the
tops of my list are names and namespaces. The complexity it adds
pushes the property lookup resolution algorithm way beyond what
programmers, including myself, can reliably predict. (Grain of salt
alert: I had the same reaction to C++'s overload resolution rules and
their interaction with C++'s implicit coercion rules. Nevertheless,
C++ is widely used. Draw from this what conclusions you will.)

AFAICT, there are three use-cases for namespaces in ES4:

a) At the package-ish level, in order to have some discipline over
inter-module-ish linkage and who gets to import/export what global-ish
variable names to whom.

b) At the property-name level, in order to be able to add additional
properties to existing objects without breaking existing code that is
already using those names for other reasons.

c) As a secure encapsulation mechanism, so that the impossibility of
mentioning some property names prevents access to the properties
associated with those names.


I don't find any of these use cases compelling. Out of order:


a) The YUI and Dojo libraries (and perhaps others) already adopts a
convention of dotted path names for namespace discipline of global-ish
variables and inter-module-ish linkage. This has the familiar look of
Java-ish package names and fully qualified class names, and is built
as a pattern, with no appreciable inconvenience, out of existing ES3
concepts.


c) As an encapsulation mechanism, this provides implicit sibling
access, as in Java. Java "private" is per-class. Joe-E inherits this
design from Java, and uses it successfully for security. Any instance
of a Joe-E class can implicitly see the private members of any other
instance of that class. By contrast, Smalltalk's instance variables
are encapsulated per-instance. E and Caja follow Smalltalk, and use
this design successfully for security.

We have discussed on cap-talk and/or e-lang the confused deputy
hazards of Joe-E's per-class encapsulation as contrasted with E's
per-instance encapsulation. The problem is that the greater access
siblings have to each other -- beyond what clients have to each --
provides an implicit form of rights amplification. (See section 10.2.1
and Figure 10.1 of  for how
rights-amplification raises confused deputy hazards.) Our conclusion
was that this is indeed a hazard, but a lint-like tool for Joe-E could
mitigate the danger since such amplification is always statically
detectable. (Access to a non-public member of something other than
"this".)

ES4 has no such reliable ability to detect amplification statically.
Therefore, the confused deputy hazards inherit in using rights
amplifications will be non-obvious and difficult to detect. Better to
have an attribute-based encapsulation mechanism, that explicitly
distinguishes public vs private properties, and to use per-instance
encapsulation of private properties. (Adding a "private" attribute to
properties would be much more elegant that Caja's current "does it end
with an underbar?" test.) When rights amplification is actually
needed, better to express it explicitly by other means, such as the
sealer/unsealer pairs shown in the Caja spec.


b) Having dispensed with the utility of ES4 namespaces as a secure
encapsulation mechanism, there remains the issue of using them by
convention/discipline to avoid accidental collisions. Experience with
Smalltalk and the Prototype library for JS shows that there really is
a genuine problem here. In Smalltalk, hundreds of separately written
extensions add methods to Object. Early JavaScript libraries like
Prototype did likewise. Existing Smalltalk virtual machines, going
back at least to Smalltalk-80, already support method dispatch on
non-string selectors, so an ES4-like solution was already possible
with only a change to the compiler. I know of at least three designs
(the best is )
to bring this power to Smalltalk. The T language (an object-oriented
variant of Scheme) and Joule (E's immediate ancestor) all had some
form of first-class selector
.  In all of
these, as in ES4, a source identifier is first looked up in a lexical
context to find a first-class selector object. Then, this selector
object is used for method-dispatch (i.e., property lookup).

None of these caught o

Re: complexity tax

[Mark S. Miller]

2008/5/19 Brendan Eich <[EMAIL PROTECTED]>:
> On May 19, 2008, at 6:54 PM, Mark Miller wrote:
>
> If I could
> have a language with some of the syntactic conveniences of ES4 but
> without ES4's semantics, I'd be quite happy.
>
> What semantics in particular, can you pick on something specific that's not
> in your classes as sugar proposal (rather than have me guess)?

Good suggestion. Will do. Top of my list will be first-class Name objects.

> BTW, since
> you missed the cuts in the spreadsheet
> [http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2],
> you may have missed the optional
> type checker being cut too: 'use strict' is good-taste mode, a la Perl and
> in accord with discussions we've had at the last two TC39 meetings.

Got those, and am quite happy about them. As for the spreadsheet, I'm
very impressed by the amount of red in the Apple column. Apple folks,
can you say more about this?

Brendan, how should one derive from the spreadsheet what the current
ES4 decisions are? Should we have a column for that?


> Thanks for the kind words, although since neither 3.1 nor 4 is done yet,
> specific constructive criticism is even better.

Understood. Will do.

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

Re: complexity tax

[Brendan Eich]

On May 19, 2008, at 6:54 PM, Mark Miller wrote:


If I could
have a language with some of the syntactic conveniences of ES4 but
without ES4's semantics, I'd be quite happy.


What semantics in particular, can you pick on something specific  
that's not in your classes as sugar proposal (rather than have me  
guess)? BTW, since you missed the cuts in the spreadsheet, you may  
have missed the optional type checker being cut too: 'use strict' is  
good-taste mode, a la Perl and in accord with discussions we've had  
at the last two TC39 meetings.


Thanks for the kind words, although since neither 3.1 nor 4 is done  
yet, specific constructive criticism is even better.


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

Re: complexity tax

[Mark Miller]

On Mon, May 19, 2008 at 4:46 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> These essential features will be added without
>> resorting to new syntax.
>
> New syntax is what's needed to make these usable. Who wants to use
> Object.defineProperties on a closure to bind a read-only property
> when you could use 'const'?
>
> The problem with Object.defineProperties, apart from standardizing it
> in two committees, is the verbosity and (at the limit) overhead.
> There's really no reason not to have better UI for the underlying
> semantics.


I agree that it would be nice to have better syntactic conveniences
for some of these features. I also agree that the ES4 syntax has some
decent conveniences. Given the inescapable legacy compatibility
constraints, it's amazing how well they turned out; kudos! If I could
have a language with some of the syntactic conveniences of ES4 but
without ES4's semantics, I'd be quite happy. My "Classes as Sugar"
proposal 
suggests how some of ES4's syntactic conveniences  could be applied to
a language with only ES3.1's semantics.

However, so long as ES4 ties these syntactic conveniences to ES4's
semantics, ES3.1's successors cannot grow in the direction of the
"Classes as Sugar" proposal without violating the subset agreement.
Given our current situation, I think maintaining the subset agreement
is more important. For some, ES3.1 is too little. For others, ES4 is
too much. From prior discussions, I don't believe it's possible to
find something in the middle that we can all agree on -- though I
would still like to!

-- 
Text by me above is hereby placed in the public domain

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

Re: complexity tax

[Brendan Eich]

On May 19, 2008, at 4:32 PM, Douglas Crockford wrote:

> Brendan Eich wrote:
>> On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:
>>
>>> Let us take action instead of throwing opinions around:
>>> Brendan: What new features that can not be implemented via code
>>> constructs now?
>>
>> This is reductionism, therefore between silly and wrong, but I  
>> will list
>> a few things:
>>
>> * you can't make read-only properties in ES3;
>>
>> *you can't make don't-delete properties of plain old objects (only  
>> vars
>> in closures);
>>
>> * you can't make objects that cannot be extended;
>>
>> * you can't make don't-enum properties in plain old objects;
>
> It looks like these omissions will be corrected in ES3.1 by the
> Object.defineProperties function.

Of course, Ric asked "What new features [...] can not be implemented  
via code constructs now?" Code constructs added in 3.1, with or  
without new syntax, don't count.


> These essential features will be added without
> resorting to new syntax.

New syntax is what's needed to make these usable. Who wants to use  
Object.defineProperties on a closure to bind a read-only property  
when you could use 'const'?

The problem with Object.defineProperties, apart from standardizing it  
in two committees, is the verbosity and (at the limit) overhead.  
There's really no reason not to have better UI for the underlying  
semantics.

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

Re: complexity tax

[Douglas Crockford]

Brendan Eich wrote:
> On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:
> 
>> Let us take action instead of throwing opinions around:
>> Brendan: What new features that can not be implemented via code
>> constructs now?
> 
> This is reductionism, therefore between silly and wrong, but I will list 
> a few things:
> 
> * you can't make read-only properties in ES3;
> 
> *you can't make don't-delete properties of plain old objects (only vars 
> in closures);
> 
> * you can't make objects that cannot be extended;
> 
> * you can't make don't-enum properties in plain old objects;

It looks like these omissions will be corrected in ES3.1 by the 
Object.defineProperties function. These essential features will be added 
without 
resorting to new syntax.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: complexity tax

[David Teller]

Well, most languages have better support for libraries than C or C++.
But there are things that even C has and JS<2 doesn't:
* #include
* a linker
* a somewhat standard manner of distributing these libraries (.a or .so)
* arguably, a [not necessarily hacker-proof] mechanism for sharing
symbols between several components without exposing them to the client.

Note that I'm not attempting to advocate the merits of #include, which I
find rather ugly. I also have no idea whether the linker is part of the
spec or not -- but then, I wasn't discussing specs, more developer
experience, and linkers have been part of the standard package for as
long as I've been programming.

Now, with JS<2, to get something linke #include + linking (or Java's
import), you need to use somewhat more convoluted methods. In addition,
all the techniques I have seen require some hard-wiring inside the
document, which may be good for small webpages, but looks like a rather
bad practice when you're talking about whole applications: essentially,
this is equivalent to putting all your #includes inside the UI code.
Finally, while the methods may work in a webpage, not all of them apply
well to non-web JS -- I'm thinking about off-line extensions, XPCOM or
server-side JS.

This strikes me as a good reason to improve library management in JS.
Which was the case last time I looked at ES4, although I may have missed
a few developments on that front.

Cheers,
 David

On Thu, 2008-03-27 at 10:30 -0400, Mike Shaver wrote: 
> I don't quite understand this -- could you give an example of a
> language that has better support for libraries as part of its language
> specification?  I don't think the C specification includes linking (or
> even the ABI, though C++ grew an ABI specification later), so it seems
> to be about at the same point of "get your code into scope somehow".
> Browsers use 

Re: complexity tax

[Neil Mix]

> I think this is the specific point of disagreement. Complexity in a  
> language
> does not necessarily reduce the complexity of programs. I think the  
> opposite may
> be truer. The difficulties we have had in the development community  
> since 1999
> were not due to over-minimization. They were due to features that  
> did not work
> as expected or reliably over the various brands and versions. I  
> think that with
> minimal changes we can significantly improve this language. Most of  
> the changes
> I would make would make it simpler, not more complex. And of course,  
> our
> overwhelmingly most important problem, insecurity, is not addressed  
> by this
> proposal. The proposal is trying to solve a problem from a 2000  
> viewpoint. We
> have moved on since then. We have new problems now, and the proposal  
> does not
> match them.

The community of JS developers is wide and deep, and the applications  
of JS differ dramatically in scope.  I, for one, am a member of "we"  
who couldn't disagree with you more.  So who exactly is "we"?  What  
evidence do you have that simplification would meet the needs of the  
vast majority of "us"?

I say this not to be argumentative, but to point out that the  
"development community" can't be generalized so easily as you  
suggest.  You represent an important voice in the community to be  
sure, but it's by far not the only one.

> I believe that it will be easier to improve the performance of the  
> language by
> simplifying it. That performance improvement will be critical as we  
> move toward
> mobile.

Do you have evidence to support this claim?  Which simplifications can  
you point to where objective evidence demonstrates that performance  
will improve?

It's all well and good to invoke the "simple is better" mantra (no  
disagreement here), but it needs to be backed up with evidence, detail  
and definition.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: complexity tax

[Mike Shaver]

On Thu, Mar 27, 2008 at 7:06 AM, David Teller
<[EMAIL PROTECTED]> wrote:
>  In my experience, the main problem with JS was the impossibility of
>  extending it. That is, no notion of libraries and no built-in
>  pre-processor (although reflexivity could be used for similar purposes).
>  A consequence was that any extension deemed important by the developers
>  of a browser had to be bolted-on in non-specified manners.

I don't quite understand this -- could you give an example of a
language that has better support for libraries as part of its language
specification?  I don't think the C specification includes linking (or
even the ABI, though C++ grew an ABI specification later), so it seems
to be about at the same point of "get your code into scope somehow".
Browsers use 

Re: complexity tax - mobile devices - Microsoft + Adobe tools + future browsers

[David Teller]

On Wed, 2008-03-26 at 14:56 -0700, ToolmakerSteve98 wrote:
> I am putting together a toolset that bridges .NET & Silverlight development 
> tools with Adobe's tools. I've decided to do a proof-of-concept for a given 
> scope of language, specifically using type-inference technology in F# to 
> provide a statically-type-bound compilation of a subset of ES4. 

Do I understand correctly that you're compiling your subset of ES4 to
F# ? Sounds interesting. Do you keep a blog on that ?

Cheers,
 David


-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

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

Re: complexity tax

[David Teller]

On Wed, 2008-03-26 at 08:23 -0700, Douglas Crockford wrote:
> The difficulties we have had in the development community since 1999 
> were not due to over-minimization. They were due to features that did not 
> work 
> as expected or reliably over the various brands and versions. 

In my experience, the main problem with JS was the impossibility of
extending it. That is, no notion of libraries and no built-in
pre-processor (although reflexivity could be used for similar purposes).
A consequence was that any extension deemed important by the developers
of a browser had to be bolted-on in non-specified manners.

Now, all the features I see en ES4 are nice (my favorite being the
hybrid type system, although type inference is going to be a heck to
design and implement) and I can see myself using most of them, but I
would have been content with just the addition of libraries and
pre-processor. 

Cheers,
 David
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

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

Re: complexity tax

[Brendan Eich]

On Mar 26, 2008, at 4:47 PM, Ric Johnson wrote:

> On 3/26/2008, "Brendan Eich" <[EMAIL PROTECTED]> wrote:
>> This is reductionism, therefore between silly and wrong,
>
> Can you explain the above fragment?

The whole of a language is more than the sum of its parts. The lambda  
calculus is enough for computation but no one wants to use only it.  
Danny Hillis built a computer from tinkertoys once...

>
>> * you can't make read-only properties in ES3;
>
> I think I can!

How?

> but is the intention sugar or hacker proof?

Hacker.

>> *you can't make don't-delete properties of plain old objects (only
>> vars in closures);
>
> Again, I can make it pretty darn hard to remove privledged fields  
> without
> killing the tree,

How?

>> * you can't make objects that cannot be extended;
>
> This may be true.  But I think the crazy guy that invented  
> livescript did
> this to allow the power of prototype and redefine the Object/ Function
> constructors actually had a good idea: JS is not a CLASSical language.

That does not solve problems where integrity matters more than it  
does for the obvious use-cases I had in mind in favoring mutability.

>> * you can't yield from a function to its caller, saving state
>> automatically in local variables, and send a value back to the
>> suspended activation of that function.
>
> I actually have a hack that used recursion, a global hash, timers, and
> closures that effectively did YIELD (and it worked most of the time  
> too!)

I don't think you read what I wrote: save local variables, resume the  
same function activation. Sure, you can implement state machines with  
other techniques, which are ugly and hard to use by comparison :-P.

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

Re: complexity tax

[Ric Johnson]

Brendan,

I admit to being a lurker and a bit of a troll, except the discussions I
inspire are actually help me understand.  Inso much that the community
also learned, mayhaps I am an 'ethical' troll.

On 3/26/2008, "Brendan Eich" <[EMAIL PROTECTED]> wrote:
>This is reductionism, therefore between silly and wrong, 

Can you explain the above fragment?

>* you can't make read-only properties in ES3;

I think I can! Maybe a bad developer could re-define parts of my objects,
but is the intention sugar or hacker proof?

>*you can't make don't-delete properties of plain old objects (only
>vars in closures);

Again, I can make it pretty darn hard to remove privledged fields without
killing the tree, and I ususally use plain old objects (poo) as data
only.

>* you can't make objects that cannot be extended;

This may be true.  But I think the crazy guy that invented livescript did
this to allow the power of prototype and redefine the Object/ Function
constructors actually had a good idea: JS is not a CLASSical language.

>* you can't yield from a function to its caller, saving state
>automatically in local variables, and send a value back to the
>suspended activation of that function.

I actually have a hack that used recursion, a global hash, timers, and
closures that effectively did YIELD (and it worked most of the time too!)

> It is now shrinking to meet practical
>budgets involving Ecma member consensus, prime mover commitments,
This is good news that we are coming to consensus, even if it is only for
timelines (for now).

Thank you for your considered response!
- Ric

P.S. I would also love to hear from Doug on this, if you are out there!
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: complexity tax

[Garrett Smith]

On Wed, Mar 26, 2008 at 8:23 AM, Douglas Crockford
<[EMAIL PROTECTED]> wrote:
> Brendan Eich wrote:
>
>  > And over-minimizing a language imposes a complexity tax on programmers
>  > using it.

That is true.

>  > To decide whether to evolve JS or shrink it, you need only look at two
>  > things: 1) problems JS hackers run into every day, which are not solved
>  > by more idiomatic functional programming hacks that add cycle and space
>  > bloat to their libraries and applications; 2) competition from other
>  > languages in runtimes vying to displace the browser.
>
>  I think this is the specific point of disagreement. Complexity in a language
>  does not necessarily reduce the complexity of programs.

Not necessarily, but to be specific, simply adding 'private' access
modifier would avoid a closure. This is good because its a lot more
convenient and a lot clearer.

I think the opposite may
>  be truer. The difficulties we have had in the development community since 
> 1999
>  were not due to over-minimization. They were due to features that did not 
> work
>  as expected or reliably over the various brands and versions.

That is true. Implementation differences are significant difficulties.
Other difficulties had to do with browser differences/competing
technology platforms (, document.all).

There are also limitations to the language itself that cause problems
(no access modifiers, limited typechecking, enumeration). I disagree
that limitations in the language did not cause difficulties. I think
the opposite is true. I think that developers ran into problems when
trying to add to Object.prototype. I think developers have struggled
trying to figure out if [some_object] was a function or array. I think
that developers exploited closures for all that closures had to offer.
Closures are the most useful thing we have because there simply aren't
other alternatives available.

Garrett

>
>
>  ___
>  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: complexity tax

[Brendan Eich]

On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:

> Let us take action instead of throwing opinions around:
> Brendan: What new features that can not be implemented via code
> constructs now?

This is reductionism, therefore between silly and wrong, but I will  
list a few things:

* you can't make read-only properties in ES3;

*you can't make don't-delete properties of plain old objects (only  
vars in closures);

* you can't make objects that cannot be extended;

* you can't make don't-enum properties in plain old objects;

* you can't yield from a function to its caller, saving state  
automatically in local variables, and send a value back to the  
suspended activation of that function.

The last is generators, but let's suppose that we add those. I'm  
intentionally leaving out things that are hard to do, but can be  
done, with closures (e.g., guaranteeing that |this| binds to a  
particular object when a method is called; or guaranteeing that a  
particular method *will be* called by a given name on an object).

Suppose further that you chose the absolute minimal set of additions  
to support some semblance of a solution for the first four bullets.

My response is that adding a few meta-methods to flip property  
attributes is not thereby "enough", since it is still incredibly  
verbose, error-prone, inefficient, and subject to "in the middle of  
construction" integrity attacks to build up "classes" or other ES4  
features using objects with const/permanent/non-enumerable additions.  
Almost no one will write such "classes" out by hand.

I noted years ago to Doug (after a talk at Yahoo! I gave) how a macro  
system would help programmers use some primitives better without  
adding more surface syntax. He wondered whether we shouldn't do  
macros first. Problem is macros are not theoretically worked out yet  
-- and that's in the context of Scheme. So rather than starve the  
patient further, I argue we should be willing to add syntactic  
conveniences as well as syntax for new substance. Macros may come,  
and much can be recast in terms of them, and the ecosystem can take  
over the business of syntactic extension, to a great extent.

Anyway, I don't think my answer here helps decide what to do.  
Opinions and tastes vary about things like syntax, dynamic meta- 
programming using fewer primitives vs. declarative new forms that can  
be (optionally) statically checked, etc. Some people will always  
prefer to use fewer primitives. It seems better to me to grow  
JavaScript based on existing "design patterns" used (at some cost) on  
top of ES3, and based on solutions from "nearby" languages such as  
Python and ActionScript 3 (to take just two examples).

Even this does not mean anything particular about complexity budgets.  
I will say this: ES4 has overspent its complexity budget in order to  
explore a large design space. It is now shrinking to meet practical  
budgets involving Ecma member consensus, prime mover commitments,  
fatigue effects, community expectations, and the like. No one working  
on ES4 wants it to be like Perl 6. We aim to finish this year. So  
you'll see proposals like multimethods getting deferred.

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

Re: complexity tax - mobile devices - Microsoft + Adobe tools + future browsers

[ToolmakerSteve98]

"Ric Johnson" wrote:
>>I wrote:
>>> Javascript and Flash and a Silverlight language that was powerful enough
>>> to also use server side a la Java.
>>>
>>> Does such a language need to be as extensive as ES4? Probably not.
>
>um... You mention the solution in your question: Silverlight.
>
>IMHO, it is Microsoft attempt to allow C# in the browser, work like
>flash, and you can write server side code.
>
>Silverlight may not be as broad based as Javascript right now, but it
>does have Microsoft behind it.

Exactly. And rather than continue the split between Microsoft and other 
alternatives, I am hunting for common ground, at least at the language 
level.

I currently intend to target Microsoft CLR-based mobile devices; i.e. 
Silverlight. When I took a close look at Action Script 3 in Flash Player 9, 
I realized that Flash finally had a language powerful enough to fit in with 
my plans, as an alternate platform. This lead me to this proposed ES4 work. 
I believe it would be a huge win for everyone (even Microsoft IMHO, though 
that is not the conclusion that Microsoft members of this discussion have 
reached), if these three important pillars all supported a common, powerful 
language:
1) Silverlight and other .NET platforms, including server side;
2) Adobe's web design tools, currently dominant in the marketplace;
3) Browsers' client side language; e.g. Javascript "2".

I am putting together a toolset that bridges .NET & Silverlight development 
tools with Adobe's tools. I've decided to do a proof-of-concept for a given 
scope of language, specifically using type-inference technology in F# to 
provide a statically-type-bound compilation of a subset of ES4. I hope to 
demonstrate high performance and compactness when targeting CLR, both on 
Silverlight, and on Windows Server running ASP.NET. And compatibility with 
Flash 9, and the proposed ES4.

The goal is a total solution that builds on current and future work by both 
Microsoft and Adobe, as well as possible future browsers, once someone makes 
a Tamarin/ES4 plug-in for Firefox.

~TMSteve 

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

Re: complexity tax - Addendum

[Ric Johnson]

On 3/26/2008, "ToolmakerSteve98" <[EMAIL PROTECTED]>
wrote:

>I wrote:
>> Javascript and Flash and a Silverlight language that was powerful enough
>> to also use server side a la Java.
>>
>> Does such a language need to be as extensive as ES4? Probably not.

um... You mention the solution in your question: Silverlight.

IMHO, it is Microsoft attempt to allow C# in the browser, work like
flash, and you can write server side code.

Silverlight may not be as broad based as Javascript right now, but it
does have Microsoft behind it.

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

Re: complexity tax - Addendum

[ToolmakerSteve98]

I wrote:
> From my perspective, this is about:
> . Flash; Silverlight; Java (client side).
>
> Three major approaches requiring large plug-ins to provide a rich 
> environment. Notably all three approaches have languages substantially 
> beyond Javascript. As a toolmaker, I would love to see convergence between 
> Javascript and Flash and a Silverlight language that was powerful enough 
> to also use server side a la Java.
>
> Does such a language need to be as extensive as ES4? Probably not.
>
> Is this more urgent than the topics Douglas mentions? That seems worthy of 
> more discussion.

I want to add that one factor is what different people/companies are 
motivated to do. Since there is currently momentum to pin down an advanced 
language, I figure it is worth not interfering with that momentum. Let the 
current process go to completion, so that we have something specific to poke 
at.

Given the [literally] global ramifications of adopting ES4, it might then 
make sense to pause, rather than seeking a vote on adoption. Spend time with 
ES4 implementations; grapple with security and other pressing concerns. Make 
at least one straw proposal for deferring some features.

~TMSteve 

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

Re: complexity tax

[ToolmakerSteve98]

"Douglas Crockford" wrote:

> Brendan Eich wrote:
>> 2) competition from other
>> languages in runtimes vying to displace the browser.
>
> I can't make sense of your point about competition.

>From my perspective, this is about:
. Flash; Silverlight; Java (client side).

Three major approaches requiring large plug-ins to provide a rich 
environment. Notably all three approaches have languages substantially 
beyond Javascript. As a toolmaker, I would love to see convergence between 
Javascript and Flash and a Silverlight language that was powerful enough to 
also use server side a la Java.

Does such a language need to be as extensive as ES4? Probably not.

Is this more urgent than the topics Douglas mentions? That seems worthy of 
more discussion.

Best Regards, ~TMSteve 

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

Re: complexity tax

[Ric Johnson]

On 3/26/2008, "Douglas Crockford" <[EMAIL PROTECTED]> wrote:

>
>I think this is the specific point of disagreement. Complexity in a language
>does not necessarily reduce the complexity of programs. I think the opposite 
>may
>be truer. The difficulties we have had in the development community since 


I think this is THE point of prose rather than technique in that I can
argue either side.
An example is Microsoft’s LINQ - it is already implemented in .Net 3.5. 
I can do the same effects using delegates to static IEnumerable in older
versions of .Net but it would take me several (dozen) more lines of
code.  When compiled, the result may be the same, but my implementation
may not be standard.  (Doing it my own way may allow me to discover
something better, but that is another discussion)

I respect both sides:  I trust Brendan as the language designer, but I
can not get over Doug’s fear of ‘The Ghost of Netscape’.

Let us take action instead of throwing opinions around:
Brendan: What new features that can not be implemented via code
constructs now?
Doug: Please give concrete example of YUI code that accomplishes
something proposed

Then we, as computer SCIENTISTS can calculate the complexity ratio of
code vs. language implementation.  We could keep on arguing about speed
and best specific algorithms after that if you want.

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

complexity tax

[Douglas Crockford]

Brendan Eich wrote:

> And over-minimizing a language imposes a complexity tax on programmers 
> using it. This happened long ago with JS1 and it was compounded by 
> foot-dragging monopolist misconduct since 1999.
> 
> To decide whether to evolve JS or shrink it, you need only look at two 
> things: 1) problems JS hackers run into every day, which are not solved 
> by more idiomatic functional programming hacks that add cycle and space 
> bloat to their libraries and applications; 2) competition from other 
> languages in runtimes vying to displace the browser.

I think this is the specific point of disagreement. Complexity in a language 
does not necessarily reduce the complexity of programs. I think the opposite 
may 
be truer. The difficulties we have had in the development community since 1999 
were not due to over-minimization. They were due to features that did not work 
as expected or reliably over the various brands and versions. I think that with 
minimal changes we can significantly improve this language. Most of the changes 
I would make would make it simpler, not more complex. And of course, our 
overwhelmingly most important problem, insecurity, is not addressed by this 
proposal. The proposal is trying to solve a problem from a 2000 viewpoint. We 
have moved on since then. We have new problems now, and the proposal does not 
match them.

I believe that it will be easier to improve the performance of the language by 
simplifying it. That performance improvement will be critical as we move toward 
mobile.

I can't make sense of your point about competition. The web's competitors all 
provide access to multiple languages, including JavaScript. In the unlikely 
case 
that the proposed language is successful, I would expect them to support it 
too. 
It would seem that the web would be more competitive if it also offered 
multiple 
languages. I don't believe that a single, all-inclusive monster language will 
be 
competitive.


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