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

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

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

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

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

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

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 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: [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: [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

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

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?

>> 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: "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: "Harmony is a super-set of ES5 strict"

>> So I think it might be a little misleading to say Harmony is strict-only. > > Who ever said that? :-P Yikes... not playing who-said-what. For whatever reason, Waldemar got the impression that someone said it, and I'm correcting the misconception, that's all. > I've written that Harmony is b

Re: Multiple globals and direct/indirect eval

Hi Jeff, I agree that the spec should deal with multiple global objects. I'm aware of a few of the subtleties of multiple globals, but I wouldn't be surprised if there are more. Thanks for raising this one. I created a placeholder strawman last week, because I've been intending to get into this

Re: Additional language features

> But I miss the linear algebra library to go with it. Can you send references to example libraries for other systems that you would like to see? > Especially for the "binary data" approach, as it's removing an order > that might be implicitly known - sorry, I don't know how to express that > be

Re: Additional language features

> A big favourite of mine (I'm biased, though...) is the Eigen2 library > (LGPL3+): I can't speak for other browser vendors, but I think that license isn't compatible with Mozilla's codebase. But thanks for the reference. > Using the small, fixed size subset of that lib and exporting the > inter

Re: [Harmony Proxies] Adding a defineProperties derived trap

Hi David, We have a strawman for making the enumeration order well-specified: http://wiki.ecmascript.org/doku.php?id=strawman:enumeration Would that not be sufficient for the defineProperties case? I'd prefer that to adding another trap. Dave On Mar 12, 2011, at 1:15 PM, David Bruant wrot

Re: [Harmony Proxies] Adding a defineProperties derived trap

[Oh sorry, I'm behind on the iteration-order mega-thread. I'll have to catch up.] On Mar 14, 2011, at 1:16 PM, David Herman wrote: > Hi David, > > We have a strawman for making the enumeration order well-specified: > > http://wiki.ecmascript.org/doku.php?id=strawm

Re: yield and new : SpiderMonkey and the draft Spec

> P.S.: > > A small change, e.g. can be to make next as a getter since it doesn't accept > arguments. > > g.next; // 1 > g.next; // 2 > > But, it's a cosmetic and actually not so needed change. -1 The purpose of the next interface is to change the state of the iterator. A getter interface ob

Re: yield and new : SpiderMonkey and the draft Spec

I agree with Dmitry on these points. In short: the new Generator(...) syntax still requires its argument to be a generator function, so you've just added pointless extra make-work to create one. And as Dmitry points out, you can always implement that constructor yourself in JS. What I think is

Re: Bringing setTimeout to ECMAScript

It seems to me there are a couple pieces to Mark's concurrency proposal. One part is formalizing the event queue that already exists. Another part is introducing new concepts and features to the language (like promises and vats). I want to hear what Mark has to say at the TC39 meeting, but my gu

Re: Bringing setTimeout to ECMAScript

>> It seems to me there are a couple pieces to Mark's concurrency proposal. One >> part is formalizing the event queue that already exists. > Is this already done in the current proposal? Because I haven't found it. Sorry, I guess I should say, we can't add concurrency without having it be comp

Re: linear-time weak-map gc

Hi Felix, I have a note on the wiki page offering a less algorithmic approach to specifying weak maps. I don't think we should be putting GC algorithms in the spec at all; that would be overspecification. Instead, we should just focus on defining reachability, and leave implementors free to com

Re: linear-time weak-map gc

> It's weird, though--specifying anything about WeakMap reachability at > all is a lot like specifying proper tail calls: it's hard to say what > you mean without being a lot more concrete about the abstract machine > the language runs on than you would be otherwise. The real requirement > is simpl

Re: linear-time weak-map gc

size measurements. (They'd be especially hard to automate, but I'd rather have the ability to test manually than none at all.) Anyone have experience with this from, say, the JVM and its weak references? Dave On Mar 20, 2011, at 8:20 AM, David Herman wrote: >> It's weird, t

Re: Bringing setTimeout to ECMAScript

> I said that WHATWG has done some on work specifying what currently > happens in browser (joining with your idea of "be[ing] compatible with > existing event queue semantics"). One idea would be to see what they've > done, get inspired and specify the event queue in ECMAScript. OK. I'm on board f

Re: linear-time weak-map gc

's algorithm > or one that makes different tradeoffs (e.g., a rare O(N**2) in exchange for a > lower constant overhead in the typical case), we should clearly leave to > implementors. There is indeed nothing normative about this. > > > On Sun, Mar 20, 2011 at 7:20 AM,

Re: linear-time weak-map gc

> typically this is seen as a quality of implementation issue. Note the we (and > most other language specs.) don't say much (or anything) about GC in general. > In one sense we don't need to say anything else about WeakMaps because it > would be a lower quality implementation to retain objects

Re: About private names

> right now, bracket notation is a superset of dot notation, but it would no > longer be under the proposed syntax. I'm afraid I can't figure out what this means, but it doesn't sound true to me. > This gets at my other objection. Code is far harder to debug when every > single property lookup

Re: About private names

>>> right now, bracket notation is a superset of dot notation, but it would no >>> longer be under the proposed syntax. >> >> I'm afraid I can't figure out what this means, but it doesn't sound true to >> me. > > Right now, everything that can be expressed via dot notation has an analog in > b

Re: About private names

Brendan and Irakli both beat me to the punch here -- I would really like to see stronger evidence that "an entire lexical scope" is really so onerous. Everything you say about how Java mitigates the problem is just as applicable to Harmony. > Java doesn't formalize this, you're right — but if I

Re: A couple of questions regarding let, hoisting and block scope

> Hoisting isn't nice in general, and from the "no use beforedeclaration" > in [1], it seems that let bindings won't be hoisted, > not even to their enclosing block. That page is not yet complete. There's plenty more work to do on it, but we probably won't be able to find much time to do

Re: Lexically Scoped Object Extensions (was About private names)

I wish you would make your proposal more precise; right now we have to infer it from your single example. In my conversations with several others on the committee, I'm already seeing lots of confusion about the semantics of what you are describing here. Can you write this up as a strawman in mor

Re: Infix Operators (Re: March 22/23 notes)

Hi Claus, Interesting idea; I'd never considered lifting some of these good syntax ideas from Haskell before. One issue with the Haskell `...` syntax directly is conflict with the quasi-literals proposal, but we can think about alternatives offline (let's *not* get into a discussion of concret

Re: Inner functions and outer 'this' (Re: That hash symbol)

The questions about eval look mostly unproblematic to me. In ES5-strict and Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine the semantics would be pretty straightforward, if problematic; but eval being able to affect its caller's scope is problematic anyway, so it

Re: extends keyword instead of

> Allen makes the point that class D extends B {...} may look too much like > languages where it means something quite different. Yeah, I just don't buy the argument that having different semantics should lead to different syntax: it proves too much. By definition, JS has a different semantics

Re: Inner functions and outer 'this' (Re: That hash symbol)

> I am really astonished to hear protection keys being thought > of as "brittle" under transformation: that is just the opposite of what they > are about! Sorry to astonish you. :) > Executive summary: > > - de Bruijn indices are a good assembly language of > binding constructs, suitabl

Re: Inner functions and outer 'this' (Re: That hash symbol)

This is what Sam is referring to -- we've been talking about exactly such a feature. I continue to believe that something like the ^this feature we've been talking about is as likely to introduce bugs as it is to fix bugs. It's like special language support for off-by-one errors. Dave PS A pro

Re: Inner functions and outer 'this' (Re: That hash symbol)

On Mar 29, 2011, at 7:26 AM, David Herman wrote: > This is what Sam is referring to -- we've been talking about exactly such a > feature. Sorry if that wasn't clear: at the last face-to-face we talked about allowing you to give your own custom name for the |this|-parameter, s

Re: Inner functions and outer 'this' (Re: That hash symbol)

If I've got this right, the idea of soft bind is that the function distinguishes whether it's called as a function or as a method; if called as a function, it uses the lexical binding of |this|, and if called as a method, it uses the dynamically pass-in binding of |this|. Note that the .call an

Re: Questions about Harmony Modules

Hi James, > 1) Files as modules do not need module wrapper > > Just to confirm, if a JS file contains only a module definition, the > module X{} wrapper is not needed? That's correct. > > 2) Set module export value > > > Is it possible to support settin

Re: Early spread operator

Hi Sean, Yes, I'm interested in this possibility as well. It'll probably take some careful working-through of the details to figure out exactly when/where this is doable, but it's on my radar. Thanks, Dave On Apr 1, 2011, at 7:37 AM, Sean Eagan wrote: > Why not allow the spread operator to ap

Re: Early spread operator

> Also, is it currently specified if rest parameters can have default > values? I'm more skeptical of this one. It's sort of treating empty arrays as falsey, which they aren't. And I've never noticed a need for this. But that might just be the BLUB principle in action. Do you have examples/use c

Re: Questions about Harmony Modules

> Regarding, "import M.*" via destructuring, it's also arguable whether we > don't need it since it "looks like a with". I don't see any sense in which it looks like a |with|. It's both syntactically and semantically different. Syntactically, because it's a global (or module-global) declaration

Re: Questions about Harmony Modules

> Allowing a callable module would go a long way towards bridging the > gap with "settings exports" as that is the primary use of that > feature, although it has been useful for text plugins to set the value > of an AMD module to a text string (see loader plugins section). I'll try to think up som

Re: A few more module questions

The way I think about it is, whenever you have X: Y where X and Y are identifiers, the one on the left is fixed and the one on the right is variable. - In an object literal, the one on the left is a symbolic property name and the one on the right is a variable. - In destructuring, the one on th

Re: A few more module questions

> - Does it ever make sense to access globals via "this"? If so, I assume there > will be a use case in the upcoming modules rationale document. Reflecting the globals via |this| preserves some web compatibility with programs that dynamically test the global object. It allows you some lightweig

Re: Questions about Harmony Modules

> Why I was asking -- because I saw it in your talk on ES.next, where you used > exactly this approach, i.e. module Foo = "http://modules.com/foo.js"; -- > without any `require`. That's it. No problem, I didn't mean to chastise. Just trying to keep focussed. > (should I fix my following present

Re: A few more module questions

ork. >} >} > } > > This would become more complicated with nested modules. > > On Apr 6, 2011, at 17:20 , David Herman wrote: > >>> - Does it ever make sense to access globals via "this"? If so, I assume >>> there will be a use cas

Re: Question about Weak Maps

[Disclaimer: I'm not an expert at server code. That said...] Don't you generally need to manage the policy for these kinds of requests manually anyway? In particular, you can't actually tell if a user has abandoned their session, since the browser doesn't let you know when that's happened. So i

Re: A few more module questions

Yes. The RHS of a let binding is a dynamic expression, and involves no static checking. The RHS of an import is a static module expression with validation -- it checks that the thing you're importing exists, and also prevents you from importing the same name multiple times. For example: m

Re: Removing labels

We shouldn't be making backwards-incompatible changes for features just because they can be abused. Every feature can be abused. And simplifying the completion type is not even remotely an important goal. Sometimes labels are just necessary. Sometimes you have a loop that needs an early return,

Re: Removing labels

> [aside: as far as I understand Tennent, this has nothing to do > with his principles of correspondence or abstraction, which > are often misquoted and conjured with in the archives] AFAICT, this traces back to a blog post by Neal Gafter: http://gafter.blogspot.com/2006/08/tennents-corr

Re: Removing labels

This would be brittle. Take all my arguments against the ^this feature discussed in an earlier thread and repeat them here. Labels work just fine (and better than numbers would) for this purpose. Dave On Apr 9, 2011, at 7:32 AM, Bradley Meck wrote: > I think since we can only break/continue to

Re: Removing labels

assage of a book from the 80's. Dave [1] If you don't know what call-by-value means here, don't worry about it. It has nothing to do with call-by-reference, just an unfortunate overloading of terminology. Nothing to see here, move along. On Apr 9, 2011, at 10:24 AM, Wes Garland w

Re: Setting a property in the prototype chain?

function getDefiningObject(obj, key) { if (!(key in obj)) throw new Error("key " + key + " not found"); while (!obj.hasOwnProperty(key)) obj = Object.getPrototypeOf(obj); return obj; } On Apr 10, 2011, at 10:24 AM, Axel Rauschmayer wrote: > As far as I am aware, there

Re: Dependency injection and modules?

The module system was designed to make it as easy as possible to use, both for general ease of use and to encourage modular programming. Once you move to an approach where programmers have to write their own linking specifications, it tends to get much more complicated. When you make modules mor

Re: Setting a property in the prototype chain?

I wondered if someone was going to make this point. > That should be > > while (!{}.hasOwnProperty.call(obj, key)) > > which works even if obj has an own property named 'hasOwnProperty'. Not if someone mutates Object.prototype.hasOwnProperty or Function.prototype.call. I don't think w

Re: When is a JavaScript program "correct"? (was: Setting a property in the prototype chain?)

rogrammers have to learn, and to date there's sadly not enough good, authoritative material with that kind of advice ("how not to be anti-modular"). Dave On Apr 11, 2011, at 7:07 AM, Mark S. Miller wrote: > On Sun, Apr 10, 2011 at 11:21 PM, David Herman wrote: >

Re: Dependency injection and modules?

Yes, that's the idea. Best, Dave On Apr 11, 2011, at 7:45 AM, Axel Rauschmayer wrote: > My understanding is limited, but here it goes: > > You load modules in ES.next as follows: >> module JSON = require('http://json.org/modules/json2.js'); > > > A custom module loader (loosely related to a J

Re: Existential operator

>> It'll be the WindowProxy as usual, in top level code. Dave has addressed >> what it will be in a module recently. > > I have to look on Dave's explanation, seems I missed it. But this WindowProxy > won't be assessable then, right? Will it be possible to define a new global > property/variabl

Re: Existential operator

> Cool -- is this spec'ed yet? http://wiki.ecmascript.org/doku.php?id=harmony:modules#this Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Optional : in ?: operator [was: Existential operator]

I don't think this feature is worth all this discussion or time, which is why I haven't said very much. But I don't like the idea. It *is* ambiguous, in the sense that if you wrote the grammar in the natural way it would be an ambiguous grammar, so you have to rewrite the grammar in such a way

Re: Existential operator

Think of it this way: dynamic binding no, dynamic assignment yes. > So this means, no function expressions depending on the condition? I.e.: > > this["foo"] = isDebug ? function () { ... } : function () { ... } var foo = isDebug ? function() { ... } : function() { ... } > Or I guess, such cases

Re: Existential operator

>> Or I guess, such cases will be replaced with function statements, right? >> >> if (isDebug) { >>function debug() { ... } >> } else { >>function debug() { ... } >> } > > Sure, that would be fine too. Er, sorry, no -- block-local function declarations will be block-local in Harmony. D

Re: Existential operator

Dynamic binding is bad, mmmkay? ;) Seriously, it's not an efficiency thing. Dynamic scope is easy to write but hard to predict. JS is lexically/statically scoped almost everywhere, except for with, eval, and the global object. Strict mode solves with and eval. Harmony solves the global object.

Re: Existential operator

The fact is that "dynamic scope" is used to mean multiple things: 1) the "stack-like" semantics employed by e.g. the original Lisps, and 2) any non-static scoping semantics. The former was so famous that it came to be the common usage of the term, but #1 is really just a special case of #2. I've

Re: Existential operator

> P.S.: so having this issue as already solved (as a runtime error, but still > -- the error!, not a typo-hazard!) It doesn't always produce a runtime error. If the property happens to be there, there's no error. Also, take a look at the confusing issues that arise from the dynamic semantics of

Re: Existential operator

distinction isn't actually all that important. Regardless, it's clear I caused confusion by my usage. I'll make an effort on es-discuss to be explicit about which I mean. Dave On Apr 15, 2011, at 6:48 PM, Mark S. Miller wrote: > On Fri, Apr 15, 2011 at 6:28 PM, David Herman wrot

Re: Dynamic Scope [Was: Existential operator]

Forms like `fluid-let' don't actually make dynamic decisions about *scope* -- they just mutate an existing, statically-scoped variable. We're really just talking about dynamic decisions about *where a variable is bound*, not *what the current value of its binding is*. That said, I happen to know

Re: can const functions be variable?

The const functions proposal isn't about referential transparency. They still encapsulate mutable state. What makes them "const" are the frozen property table (recall that functions in ES are objects) and the local name that's bound to the function. Dave On Apr 17, 2011, at 1:06 AM, Claus Rein

Re: Comparison operator in value proxies

I don't understand. What is "overwriting" an operator? Dave On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote: > Hello everyone, > > My idea is to disallow overwriting of === operator, and make 'compare' > operator implement == instead. Why? > > 1. === means for me that two variables have re

Re: Should ES begin to standardise pragmas?

We've talked about this on TC39. We'll probably do something, but exactly what is hard to say at this point. Designing future-proof pragma syntax requires a bit of gazing into the crystal ball... Dave On Apr 17, 2011, at 2:13 AM, Claus Reinke wrote: > Pragmas (ignorable source hints to an impl

Re: Uniform proxy API via caching call and construct traps

I don't like this idea. It's inconsistent with the behavior of the other traps, it relies too subtly on a funky stateful idiom, and it's hard to predict when the traps will actually fire (since it depends on how clients use the proxy). If there's something being set once-and-for-all I prefer it

Re: Flattening syntactic tail nests (paren-free, continued)

Claus, Thanks for the suggestions. Let me see if I can summarize them and respond briefly: * functions with expression bodies This was proposed for ES4 and implemented in SpiderMonkey. I believe there are some unfortunate ambiguities in the grammar that came up, and I think they've been treat

Re: Comparison operator in value proxies

rly early stage of design.) Dave On Apr 17, 2011, at 8:55 AM, Adam Stankiewicz wrote: > By overwriting I meant creating a trap for === operator. Sorry for confusion. > > Adam > > 2011/4/17 David Herman : >> I don't understand. What is "overwriting" an o

Re: Standardizing __proto__

> OTOH we don't need to standardize __proto__. We might instead poison-pill it > in Harmony, so opting in involves an early error on every use of __proto__, > and you have to migrate by switching to Object.getPrototypeOf or an object > initialiser extension that allows presetting the new object'

Re: wiki feed - recent changes: extraneous html encoding in links?

Hi Claus, Thanks for the bug report. I'm afraid I just don't have time for site sysadminning at the moment. Eventually we are hoping to upgrade the wiki and move it to our own (more reliable) servers, rather than the 3rd party server it's currently hosted on. But I won't be able to work on this

Re: Wiki updates to reflect last two tc39 meeting

IMO, writing these issues up as strawmen was a nice way to spark discussion but I don't see any need for them to clutter the harmony: namespace with extra proposals. Why don't we just take the decisions and fold them into the existing proxy proposals. Does that seem reasonable? Dave On Apr 28

Re: Modules and eval

That sounds like a grammar bug -- no time to debug at the moment but I'll address. A Program should be able to import but not export. Dave On May 2, 2011, at 12:50 PM, Erik Arvidsson wrote: > http://wiki.ecmascript.org/doku.php?id=harmony:modules > http://wiki.ecmascript.org/doku.php?id=harmony

Re: arrow syntax unnecessary and the idea that "function" is too long

> JavaScript won't ever be known as a outstanding functional programming > language until it has proper tail calls. This would give the language > new capabilities it doesn't have now. Proper tail calls are *already* in Harmony and totally orthogonal to the question of new function syntax. Dave

Re: arrow syntax unnecessary and the idea that "function" is too long

> Based on what evidence are "we" concluding that the majority of the > javascript developers want -> syntax for functions? The fact that > coffeescript is the hot buzzword? Was there some developer-community wide > voting or poll that I missed? Or is it that a few vocal people on these lists >

Re: arrow syntax unnecessary and the idea that "function" is too long

> But, JSConf has just 150-200 JavaScript developers in attendance. Right. The JS community has no borders, no government, no constitution, no membership cards, no census... We welcome everyone. So we have no way of instituting democratic institutions. > they are definitely not a representative

Re: Function Syntax

> I want to make the language easier to beginners to learn, streamlining the > syntax, replacing automatic semicolon insertion with statements that are > by design semicolon free. Can I ask what you mean by this? Just an illustrative example would probably be enough. Thanks, Dave __

  1   2   3   4   5   6   7   8   >