Re: "Harmony is a super-set of ES5 strict"

On Mar 3, 2011, at 5:33 PM, Waldemar Horwat wrote: > If we're saying that Harmony is strict-only, settable by a tag, what > will indirect eval and the Function constructor do if the evaluated code > doesn't start with a "use strict" directive? Yeah, "strict-only" is probably not quite the righ

Re: custom proto arg for Proxy.createFunction?

>> The simple instanceof check seems simpler and reasonably intuitive. > By "hardcoding" p instanceof Function === true I'm not proposing this -- it's already true. Try it out in SpiderMonkey: js> (Proxy.createFunction({}, function(){}, function(){})) instanceof Function true > you're b

Re: custom proto arg for Proxy.createFunction?

> With your optional argument, I see a second solution that could be > consistent. The prototype chain could contain the provided prototype > then Function.prototype ("obj --> proto --> Function.prototype --> > null" as opposed to your proposition which is: "obj --> proto --> null" > ). Hence, the

Re: custom proto arg for Proxy.createFunction?

PS Correction: it's actually a non-standard extension that regexps are callable in SpiderMonkey. So the invariant is that the only callable non-host objects are descendants of Function, or possibly host objects. This doesn't change my overall point, though. On Feb 23, 2011, at 2:26

custom proto arg for Proxy.createFunction?

I've been working on a prototype implementation of the binary data spec in pure JS (implemented via typed arrays) and I've been bitten by the lack of a standard mechanism for subclassing Function. I'm using proxies for the implementation, and Proxy.createFunction doesn't let me specify a custom

Re: [whatwg] Cryptographically strong random numbers

Too much and too complex, say I! ;) I liked your previous thinking that we should just return a fresh array. And in the interest of keeping it dead simple, let's just fix it at 32 bits -- always. Then the question is: string, array, typed array, or binary data? I say: let's make it typed array

Re: [whatwg] Cryptographically strong random numbers

An almost-conformant implementation that does not support one single function in the standard API can generally claim "conformant except for X" so I'm not too worried about such non-web cases. Dave On Feb 16, 2011, at 11:46 AM, Mark S. Miller wrote: > > > On Wed, Feb 16, 2011 at 11:36 AM, Ol

Re: Simple Modules: lazy dependency evaluation

On Jan 27, 2011, at 12:26 PM, Wes Garland wrote: > On Thu, Jan 27, 2011 at 12:37 PM, David Herman wrote: > Or here's a sort of more operational way to think about it: Start with the > outermost program. It declares a bunch of modules, some of which are loaded > fr

Re: Simple Modules: lazy dependency evaluation

1, at 11:30 AM, Kris Kowal wrote: > On Thu, Jan 27, 2011 at 9:14 AM, David Herman wrote: >> …but it is required to evaluate them in their declared order, >> deterministically. > > Would you explain how declaration order is inferred from the contents > of the unordered of

Re: Simple Modules: lazy dependency evaluation

> On the opposite side of the argument, I presume that this means that > modules are evaluated when their transitive dependencies are loaded. > This would imply that the order in which the modules are delivered, > possibly over a network using multiple connections, would determine > the execution o

Re: Simple Modules: lazy dependency evaluation

On Jan 27, 2011, at 8:38 AM, Wes Garland wrote: > Kris Kowal's query is interesting: is lazy evaluation worth considering for > Simple Modules? > >module M { >export var foo = 42; >export function bar() { return foo; } >alert("hello, world"); >} > > In the exampl

Re: Simple Modules: lazy dependency evaluation

On Jan 26, 2011, at 4:04 PM, Brendan Eich wrote: > On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote: > >> So what is the behavior if you do new m.load("la1").Foo() if you know Foo is >> an exported object? > > Sam addressed that directly ("nothing is statically known"), cited in full > below. O

Re: Simple Modules: lazy dependency evaluation

> I assume you mean m.load("la1"). No, that doesn't follow James's example at all. I'm not sure what you're talking about here. > So what is the behavior if you do new m.load("la1").Foo() if you know Foo is > an exported object? I'm not really sure what you're asking here either. > Is there a

Re: Simple Modules: lazy dependency evaluation

> You can use module loaders to do exactly this (I believe, based on my > understanding of CommonJS). It would look like: > > var ml = ... the desired module loader ... > var a; > if (someCondition) { > a = ml.load("a1"); > } else { > a = ml.load("a2"); > } Correction: you have to use callback

Re: On ES Harmony proxies extensibility

> Should we have a no-op or "sink" standard handler too? I think so, yes. Especially since you can use that to build one up that implements just the other traps you want to implement, and let the others "fail soft." Dave ___ es-discuss mailing list e

Re: On ES Harmony proxies extensibility

> We have previously discussed adding standard handlers to the specification, > i.e. an NoopHandler and a ForwardingHandler. Yes, and Tom and Mark have been working on this and making good progress. They have a forwarding handler mostly worked out, which we discussed yesterday at the face-to-fa

Re: Jan 19 meeting notes

> Sure. This is the "use noasi" or "use semicolons" idea. Or just "no asi". Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Jan 19 meeting notes

> Dave: This is abstract. Also, would rather do a general > user-extensible syntax for everything, which is perfectly doable as > part of the modules proposal. For the record, this isn't really what I was saying. For one, I'm not saying we should do user-extensible syntax *instead* of adding ne

Re: Module Loaders Question

Yes, we're working on that. :) More soon... Dave On Jan 13, 2011, at 9:59 AM, Kevin Smith wrote: > Looking at the moduleLoader.loadModule function, would relative module > locators be allowed? Would they be resolved relative to the calling module, > the module that created the loader, etc.? >

Re: Parsing allowed convenience in simple modules

Hi John, > Module declarations are only allowed at the top level of a script or module, > but for convenience, they can nest within top-level blocks, and are hoisted > to be in scope for the entire containing script or module. > > Can someone explain what this sentence means? > > To me it say

Re: Modules Question

I'll need some tool to > "bundle" all of the component modules together. I'm just trying to get a > mental picture of what such a tool would have to do. It seems like we'd need > to rewrite the module declarations (i.e. module b = "b.js";) but to what?

Re: Modules Question

text */ } > module b { /* b.js text */ } > > export a; // ? Not sure about this one > > But will the runtime know how to correctly resolve the (module b = "b.js";) > that comes from a.js? Or will that declaration have to be rewritten? > > > > On Tue, De

Re: Modules Question

There's some flexibility built in to the system via module loaders. The "filesystem modules" example is hypothetical; it assumes a built-in module loader that maps files available on the filesystem to corresponding pre-defined, nested modules. On the web, you would do almost as you suggest: >

Re: Modules Question

We would probably make it a contextual keyword so you could still use it in non-expression contexts (e.g., to the right of '.' and left of ':' in object literals), but unless we played some clever tricks, which I'm not sure would be worth it, using it as an identifier would be a syntax error. Ha

Re: for-in evaluation order

> Dave, under the spec for "Operation OwnProperties(obj)" step 1, you don't > explicitly state that these index properties are to be enumerated in numeric > order. An oversight? Oops, yes, thanks for catching that. I've updated the wiki. > Also, you misstate that indexes are "properties with va

Re: New private names proposal

On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote: > On 2010-12-23 23:55, David Herman wrote: >> On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote: >> >>> We don't know whether [] will be changed >>> at all. (In the proposal to add a @ or .# oper

Re: New private names proposal

On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote: > We don't know whether [] will be changed > at all. (In the proposal to add a @ or .# operator, it isn't.) Hm, this looks like a pretty serious misunderstanding of the private names proposal. In every variant of the proposal, the object mo

Re: New private names proposal

> You've said this "apples to oranges" thing many times. I just don't get it. > My comparisons at > show > that these two semantics address extremely overlapping use cases. For both to > be in the language, with one group (i

Re: New private names proposal

On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote: > What about adding an attribute to properties that somehow identify which > classes (in the prototype chain for protected) have access to the object? > I'll leave the "somehow" up in the air, but you could introduce a [[Private]] > attribut

Re: New private names proposal

Hi David, First of all, I think you may not be reading the current "private names" proposal. Allen wanted to change the name so he created a new page: http://wiki.ecmascript.org/doku.php?id=strawman:private_names Part of what you're reacting against is in fact what he changed (more below).

Re: New private names proposal

> I think there are some interesting ideas to explore in both D. Flanagan's > proposal and D. Herman's variations upon it. However, they both seem to be > ignoring the second primary use case that I identified: conflict-free > extensions of build-in or third party objects. While naming convent

Re: New private names proposal

On Dec 22, 2010, at 2:00 AM, David Flanagan wrote: > On 12/22/2010 01:02 AM, David Herman wrote: > >> function Point(x, y) { >> private #x, #y; >> this.#x = x; >> this.#y = y; >> } > > I keep seeing this basic construc

Re: New private names proposal

> In order for this to work you have to abandon the idea of scoped private > identifiers. I say: make all private identifiers scoped to the compilation > unit. This is the part of your suggestion that I don't like: it makes private identifiers too blunt a tool. You end up sharing with more cod

Re: New private names proposal [repost]

On Dec 21, 2010, at 10:41 PM, David-Sarah Hopwood wrote: > Again you seem to be confusing the "inherited soft fields" proposal with > the *separate* proposal on desugaring the private name syntax to inherited > soft fields. I think I may have been misunderstanding what Mark was actually proposin

Re: I recuse myself (was: Private names use cases)

> I never said I don't want syntactic support. I said I don't like the syntax > you proposed. You and Dave have now both said that you consider this to be > the main issue. Hm, I certainly didn't intend to say that. I'm not quite sure what you're referring to that I said. I don't necessarily ha

Re: New private names proposal

: > > > On Thu, Dec 16, 2010 at 5:24 PM, David Herman wrote: >> Ok, I open it for discussion. Given soft fields, why do we need private >> names? > > I believe that the syntax is a big part of the private names proposal. It's > key to the usability: in my view, t

Re: New private names proposal

> Ok, I open it for discussion. Given soft fields, why do we need private names? I believe that the syntax is a big part of the private names proposal. It's key to the usability: in my view, the proposal adds 1) a new abstraction to the object model for private property keys and 2) a new declara

Re: New private names proposal

> I'll address this last point first, since this seems to be the core issue. > The question I am raising is: given soft fields, why do we need private names? I didn't see that asked as a question; I saw it asserted, but not opened for discussion. And I disagree. Now, I happen to think it's not

Re: New private names proposal

Without new syntax, isn't soft fields just a library on top of weak maps? Dave On Dec 16, 2010, at 3:47 PM, Mark S. Miller wrote: > > > On Thu, Dec 16, 2010 at 3:23 PM, Brendan Eich wrote: > On Dec 16, 2010, at 2:19 PM, Mark S. Miller wrote: > > > Currently is JS, x['foo'] and x.foo are prec

Re: New private names proposal

> This sounds great, but doesn't this kind of violate referential > transparency? That's a loaded criticism. JS doesn't have referential transparency in any meaningful sense. But it does generalize the meaning of the dot-operator to be sensitive to scoping operators, that's true. > Couldn't the

Re: natively negotiating sync vs. async...without callbacks

> I'm not trying to open the can-o'-worms around block level changes. The above > code suggests that a 'yield' suspension of execution is local to the nearest > container { } block, in this case the try { } block. No, that's not the case. That code was not hypothetical: it works in SpiderMonkey

Re: natively negotiating sync vs. async...without callbacks

TP request: " + errorResponse.statusText); } ... foo.responseText ... bar.responseText ... baz.responseText ... }); I should also point out that the core of jstask is 7 lines of code. :) Dave On Dec 9, 2010, at 7:55 AM, David Herman wrote: > I pretty much abandoned that line of inve

Re: natively negotiating sync vs. async...without callbacks

I pretty much abandoned that line of investigation with the conclusion that generators: http://wiki.ecmascript.org/doku.php?id=strawman:generators are a good (and well-tested, in Python and SpiderMonkey) design for single-frame continuations. They hang together well; in particular, they don

Re: Nov 18 notes

>> How would a new object abstraction T customize them just for instances of T? > > By writing its own custom iteration protocol via proxies with the iterate() > trap implemented appropriately. E.g.: > >function MyCollection() { } >MyCollection.prototype = { >iterator: function()

Re: Nov 18 notes

>> for (k in keys(o)) ... >> for (v in values(o)) ... >> for ([k, v] in properties(o)) ... > > What are "keys", "values", and "properties" here? Global functions? Those are API's suggested in the strawman:iterators proposal. They would be importable from a standard module. > How would a

Re: `static` keyword from C/C++ as own closured var declaration

from if you had said: > const foo=1; > > In both cases, wrapping the declaration with a function changes its scope?? > > Allen > > -Original Message- From: David Herman > Sent: Tuesday, November 23, 2010 9:24 AM > To: Dmitry A. Soshnikov > Cc: es-disc

Re: `static` keyword from C/C++ as own closured var declaration

> Can you give a small example (it's just interesting) -- to see the issue? Sure thing. Say you're writing some code with a constant value, and somewhere inside the code you use `static': var METERS_PER_SQUARE_KILOJOULE = 17.4; ... static foo = 1; ... f(foo, METERS_PER_SQUARE

Re: `static` keyword from C/C++ as own closured var declaration

Allen suggested something like this in the September meeting. One issue people had with it was that it adds another violation of the equivalence between a statement and (function())(), which is a refactoring hazard. Put differently, if you have some code with "static" declarations in it, you ca

Re: Nov 18 notes

>> One possibility is to add a space as apparently a few other languages do: >> >> for each (var i in x) >> >> Should be unambiguously parsable and easy to understand. This has come up several times. For one, it's incompatible with ECMA-357 (E4X), which is implemented in SpiderMonkey and Rhino.

Re: Colons and other annotative characters

> I somehow suspect stringifying the iterator next() return value from for-in > machinery will not placate folks who want for-in not to be metaprogrammable. Nor would it work -- you wouldn't be able to get the values() or properties() iteration behavior, for example. It would be the worst of all

Re: Nov 18 notes

> 2a) If existing syntax is given new semantics, it should extend the existing > semantics conservatively. Otherwise, the new semantics should get new syntax. Perhaps I should have numbered that 1a'). :) Dave ___ es-discuss mailing list es-discuss@moz

Re: Nov 18 notes

> 1a) New semantics should use new syntax in a manner that clearly avoids > confusion with existing syntax. > 1b) Syntax should generally be suggestive of a reasonable interpretation of > the semantic > 1c) Harmony is not being designed using the "no new syntax" rule > 1d) There is nothing sa

Re: Nov 18 notes

> for (var i : x) ... // must be new iteration > for (var i : T : x) ... // iteration again, but parsed how? > for (var i : T in x) ... // for-in with annotated var Bummer! I'm beginning to feel more strongly again that overloading for-in, as opposed to introducing yet another syntactic va

Re: Nov 18 notes

> And (sorry, I'll try to keep replies in one message next time) "for" vs. > "forvals" does not exactly scream "keys" vs. "values", since "for" is only > about "keys" if you know ECMA-262 and expect the mystery meat of enumeration. IMO, "forvals" is a non-starter, as is "foreach" or "for each".

Re: Negative indices for arrays

> If harmony would introduce this syntax "guarded" under a new script type, > there > would at least be no danger of breaking the web (existing scripts). That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony

Re: instanceof trap and default handler for Proxies

> I assume the answer is no, but can one proxy simple modules? I can think of two ways to read this question. If you mean "can one simulate simple modules with proxies" the answer is no -- you can't dynamically simulate something with static semantics. If you mean "can one create a proxy that

Re: instanceof trap and default handler for Proxies

> How 'bout extending proxies to provide an introspection API? That's a really vague question. It would help to say what kind of introspection you had in mind. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/e

Re: ES5 errata submission

>> I've added a link at the obvious place on the EcmaScript wiki to the >> es5-discuss list. > > Thanks again. It might be a good idea to add it to >http://www.ecmascript.org/community.php > as well (and say that it's the best avenue). Good call. I've updated community.php to link to es5-disc

Re: Harmony and globals

This is discussed in the simple modules spec: http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules The top of the scope chain would not be a global *object* but there would still be global bindings. One of the things on my to-do list is to create a strawman for where all the stan

Re: value_types + struct+types = decimal

Are you suggesting a) that struct types should always be value types, or b) some sort of extension to the binary data spec that allows the creation of immutable structs that are value types? I'm afraid a) just seems unworkable -- compound binary data needs to be mutable, and its sub-components

Re: No more modes?

> Given as an opt-in, I'm puzzled about how it would > work anyway. Since it is per script, not per frame, presumably > >