Re: Alternative syntax for <|

On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote: > I'm with Allen. If ES classes can contain any initialization code, I > think it should run in program order, interleaved with top-level > statements. Anything else is just confusing. This is a great point, which I'd overlooked (not sure if Al

Re: with

On Nov 17, 2011, at 12:56 PM, Brendan Eich wrote: > This would require migration through two steps. One to ES5 strict to get rid > of the with above (which relies on ASI). The second to ES.next or whatever > retasks 'with'. I don't understand this-- that's already the case, since there's no wi

Re: with

On Nov 17, 2011, at 6:41 AM, Dmitry Soshnikov wrote: > And uses `.extend' instance method (inherited from Object) for imperative > delegation-based mixing. Sure, so that's just a method then, not an `extends` keyword. > OK, though, I'd like again to notice Scala: > > object foo extends bar { >

Re: Alternative syntax for <|

On Nov 17, 2011, at 8:00 AM, Jason Orendorff wrote: > On Wed, Nov 16, 2011 at 1:12 PM, Erik Arvidsson > wrote: >> One thing that all of these discussions are missing is the hoisting >> property of function and any possible future classes. If we use "let >> Point = ..." we lose all hoisting and th

Re: with

On Nov 17, 2011, at 6:26 AM, Mike Samuel wrote: > 2011/11/17 David Herman : >>obj with { foo: 12 } with { bar: 13 } with { baz: 17 } > > Does the below fit your syntax and isn't it lexically ambiguous with > the old "with"? > > obj > with ({

Re: with

On Nov 17, 2011, at 6:20 AM, Axel Rauschmayer wrote: >> I'm not sure what the semantics of this would be. Are you inventing >> multiple-prototype inheritance? That's not going to happen. > > > Single inheritance, a prototype chain composed from the given objects, in the > given order. An infix

Re: with

On Nov 17, 2011, at 5:37 AM, Axel Rauschmayer wrote: > [cc-ing es-discuss again] > > On Nov 17, 2011, at 14:20 , Russell Leggett wrote: > >> If <| changed to allow non-literal RHS values, I could see it getting more >> use >> >> obj <| comparable <| enumerable <| {...} >> >> but right now

Re: with

On Nov 17, 2011, at 5:16 AM, Dmitry Soshnikov wrote: >> And `extends` fails completely as the syntax. > > This is why it's so wide-spread in other languages for inheritance, right? ;) In other languages it's not a stand-alone operator but a part of class syntax. (I don't know Ruby, so maybe you

Re: with

On Nov 17, 2011, at 5:55 AM, Axel Rauschmayer wrote: > Going from > P <--has-prototype-- o > to > P --has-instance--> o > is fine with me, but it’s not the directionality of [[Prototype]]. I know Allen felt strongly about LTR here. I'm pretty sure I agree with him. Dave __

Re: with

On Nov 17, 2011, at 5:13 AM, Russell Leggett wrote: > Look closer - it is being used as a prefix operator, not an infix operator. > > extends Proto {...} There have been a few alternatives discussed in the previous thread. IMO, in each one of them, `extends` is awkward. The one you're talki

Re: with

On Nov 17, 2011, at 3:17 AM, Axel Rauschmayer wrote: >>>obj with { foo: 12 } with { bar: 13 } with { baz: 17 } > > I like the idea! As it is syntactically different in this role, errors should > be easy to spot. > > But I think `with` “points in the wrong direction” (object `obj` *with* >

Re: with

On Nov 17, 2011, at 12:10 AM, Russell Leggett wrote: >> since in this example I only used the object literal variant. (The function, >> array, etc variants do things that Object.create can't do.) > > I think this is ultimately the downfall of 'with' as a complete replacement > for <| or extends

Re: with

On Nov 17, 2011, at 3:53 AM, Dmitry Soshnikov wrote: > Once again, it's absolutely the same approach which I showed yesterday with > using `extends' > (https://mail.mozilla.org/pipermail/es-discuss/2011-November/018478.html). My point has absolutely nothing to do with semantics and everything t

Re: with

On Nov 16, 2011, at 11:27 PM, Mark S. Miller wrote: > On Wed, Nov 16, 2011 at 11:24 PM, David Herman wrote: >obj with { foo: 12 } with { bar: 13 } with { baz: 17 } > > I don't get it yet. What do you mean by "dynamically extending prototype > chains"? What do

Re: with

On Nov 16, 2011, at 11:28 PM, Dmitry Soshnikov wrote: > However, we nevertheless had/have the semantics for `with', and it may cause > confusion. Right, that's the natural objection. But... with-statements are dead, long live with-expressions! > Moreover, you need to specify that [noNewLineHer

Re: with

<| On Nov 16, 2011, at 11:27 PM, Mark S. Miller wrote: > > > On Wed, Nov 16, 2011 at 11:24 PM, David Herman wrote: > Someone who shall remain nameless shot this down when I floated it privately. > But I just have to throw this out there, because I kind of can't stop my

with

Someone who shall remain nameless shot this down when I floated it privately. But I just have to throw this out there, because I kind of can't stop myself falling in love with it... We used to have this (mis-)feature for dynamically extending scope chains, and despite being ill-conceived, it di

Re: Alternative syntax for <|

On Nov 16, 2011, at 12:11 PM, Dmitry Soshnikov wrote: > Yes, I understand, but it doesn't answer the question -- why do we need > _additional_ keyword Infix operators can be conditional keywords. That's the current plan for is, IINM. Dave ___ es-dis

Re: An array destructing specification choice

On Nov 11, 2011, at 5:31 PM, Axel Rauschmayer wrote: >> Also: we'll definitely want to allow it for splicing, so the grammar will >> have to allow it already, and symmetry/consistency argue for allowing it in >> destructuring too. Likewise for function formals and actuals. > > > Using it for s

Re: Using monocle mustache for chaining.

On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote: > Dave, if nesting were out of the question and monocle-mustache operator > always looked like an object literal as they currently exist, would it still > be as vile? With that form, I'm a big fan. I'm of multiple minds (a condition I'm gradually

Re: An array destructing specification choice

On Nov 11, 2011, at 4:23 PM, Axel Rauschmayer wrote: > It would be nice if r was optional: > [..., b0, b1, b2] = arr Agreed. Pure win, no downside. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: An array destructing specification choice

On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote: > On Nov 11, 2011, at 3:17 PM, David Herman wrote: > >> A pattern of the form >> >> [a0, a1, 〰〰, ak, ...r] >> >> desugars to >> >> a0 = %v[0]; >> a1 = %v[1]; >> 〰〰 >

Re: (Almost) everything is expression

On Nov 11, 2011, at 2:51 PM, Mike Samuel wrote: > If statements as expressions goes forward, we should look into > tweaking completion values. > > IMHO, a code maintainer who sees > >resource = ..., foo(resource) > > would expect to be able to wrap the use of resource in a try finally thus

Re: An array destructing specification choice

Late to the party, but I've brought more booze. On Nov 5, 2011, at 2:41 PM, Brendan Eich wrote: > We have: > > 1. Should an array pattern always query 'length'? > > 2. If the answer to (1) is "no", then should ... in an array pattern query > 'length'? > > On reflection and at this point in th

Re: (Almost) everything is expression

I would translate "How X is that?" as "that is very X!" :) Dave On Nov 11, 2011, at 12:26 PM, Dmitry Soshnikov wrote: > On 11.11.2011 23:44, David Herman wrote: >>>> How gorgeous is that? >>> It's normal and consistent with other blocks, I

Re: Using monocle mustache for chaining.

On Nov 11, 2011, at 10:50 AM, Erik Arvidsson wrote: > We've all looked at jQuery code and envied the conciseness of its chaining > APIs. Most of us also looked at it and thought; Yuk, making everything a > method of jQuery and always return the jQuery object is ugly. Beauty is in the eye of the

Re: (Almost) everything is expression

>> How gorgeous is that? > > It's normal and consistent with other blocks, I'd say. Sorry, that was an (American?) English colloquialism -- a rhetorical question meaning "that's gorgeous!" Dave ___ es-discuss mailing list es-discuss@mozilla.org https

Re: (Almost) everything is expression

On Nov 11, 2011, at 9:50 AM, Allen Wirfs-Brock wrote: > do-expression is a very good solution Why thank you! ;-) >> How gorgeous is that? > > not very... > > but if I see any of: > let a = do {... > let a = {|| ... > let a = { ... > I immediately know what follows. That is gorgeous...

Re: (Almost) everything is expression

On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote: > On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes wrote: > On 11 November 2011 15:33, Mark S. Miller wrote: > let a = ({ > > print('doing stuff'); > 100; > }); > > How do you know the difference between a blank block statement and a object > lit

Re: (Almost) everything is expression

On Nov 11, 2011, at 3:48 AM, François REMY wrote: > I think you strongly underestimate the "distinction" problem. ... It's > completelty unclear to me. If there's no way to tell what the "return > statement" of the block is, there's no way to implement your proposal. It's actually quite easy to

Re: (Almost) everything is expression

> Brendan and Dave mention explicit semicolon. Yes, it's seems so by the > grammar (though, have to check more precisely), but it can be acceptable > price. It's a serious price, though. Today if I write: if (q) { ... } else { ... } (f()) then ASI kicks in after the else body. If w

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 9, 2011, at 1:33 PM, Quildreen Motta wrote: > On 09/11/11 19:20, Brendan Eich wrote: >> >>> And if you need to break out of forEach, just, umm, don't use forEach. It's >>> the wrong tool for the job. >> >> Clearly people like the forEach array extra in conjunction with Object.keys. >> W

Re: Standard Prelude (was: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance))

Let's answer this once we have the module-ized version of the standard library. Which I've been promising for far too long (mea culpa). Will get started on this tonight. Dave On Nov 8, 2011, at 9:04 PM, Brendan Eich wrote: > On Nov 8, 2011, at 8:39 PM, David Herman wrote: >

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

> Still there, but write it out fully, to compare to the cited text: > > import keys from "@iter"; > for (i of keys(o)) { > body > } > > Unless we default-import a standard prelude, I think we should. > this is a bit much compared to add own as a modifier after for in for/in (not > f

Re: Lecture series on SES and capability-based security by Mark Miller

s the case. I'm just skeptical we can do it by cramming it into strict mode. Dave On Nov 8, 2011, at 3:50 PM, Mark S. Miller wrote: > > > On Tue, Nov 8, 2011 at 3:46 PM, Mark S. Miller wrote: > > > On Tue, Nov 8, 2011 at 3:33 PM, David Herman wrote: >> Perhaps

Re: Lecture series on SES and capability-based security by Mark Miller

> Perhaps __proto__ should not be writeable in "use strict"? > > That's a great idea! This never occurred to me, and I have not heard anyone > suggest this. Thanks! Doesn't work. obj[(function(__){return __ + "proto" + __})("__")] Dave ___ es-di

Re: Lecture series on SES and capability-based security by Mark Miller

This is the only one I've seen that seems like it should work, but it depends on whether SES/Caja/etc have some sort of way of neutering __proto__. Just from hacking around, I don't see much way of censoring it in SpiderMonkey. MarkM, do you have any tricks for censoring __proto__? Dave On Nov

Re: Globalization API working draft

Possibly, although it could be tough; I'll keep this in mind as we nail down the API details. Dave On Nov 3, 2011, at 11:18 AM, Axel Rauschmayer wrote: > Can loaders be composed (e.g. to use several polyfills at the same time)? One > might be able to chain them in some fashion. > >> Yes, good

Re: Globalization API working draft

Yes, good point about loaders. I would like a standard HTML way of specifying a loader to use, so you could simply say: and from then on your clients don't have to change a thing. Dave On Nov 3, 2011, at 2:00 AM, Andreas Rossberg wrote: > On 3 November 2011 01:12, David Herma

Re: Globalization API working draft

> I think we probably have an interesting question for Dave and Sam about how > to support version evolution of modules. Is there a module equivalent of > monkey patching. What if we have an implementation that exposes a "V1" module > (particularly a built-in module) and code that depends upon

Re: Minimalist Classes

> I think one piece of this is worth reiterating: As long as JS.next classes > are mostly sugar for prototypes, and prototypes aren't going to be deprecated > or removed in the next version of JavaScript (two propositions that I think > most of us can get behind) ... then it's very important tha

Re: Minimalist Classes

> But IIUC, you're proposing a semantics where you construct a brand new object > P whose __proto__ is SuperClass.prototype and then copy all the > own-properties of the RHS into P. > > Not quite. P is a constructor function (class object), SuperClass is a > constructor function. Unless I'm con

Re: Minimalist Classes

> class Fox extends Animal { > dig: function() {} > } > > Fox becomes a constructor function with a `.prototype` that is set to an > instance of Animal that has been constructed without calling the Animal() > constructor. (The usual temporary-constructor-to-hold-a-prototype two step > shuffle

Re: Minimalist Classes

Hi Jeremy, Thanks for the proposal. I've been advocating a minimalist approach to classes for a while now; I think it's a good goal. A few of us sketched out something similar on a whiteboard in the last face-to-face meeting; at least, it used the object literal body. We hadn't thought of two o

Re: yield and Promises

Hi Kris, Your proposal has a lot of similarities to http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions which was proposed this past spring. I'm not sure I follow what's top-down vs bottom-up about the two different approaches. Let me suggest some terminology that has emerge

Re: yield and Promises

You can disagree with anything if you're allowed to change the terms of the discussion. :) Brendan said JS is run-to-completion, which means that if you call a function and control returns to you, no intervening threads of control have executed in the meantime. But then you changed his example

Re: decoupling [ ] and property access for collections

> [1] http://wiki.ecmascript.org/doku.php?id=strawman:dicts [D.H. already > mentioned that this proposal does not reflect his current thinking, so beware] FWIW, I don't really know what my current thinking is. :) Dave ___ es-discuss mailing list es-di

Re: Direct proxies strawman

These are all good points. I'm not sure (1) is worth bringing back in all the "we won't let you say things you can't enforce" complexity, but (2) is maybe non-obvious enough not to be worth it. I'm backing off my "please make it null" position now. :) It actually seems pretty reasonable just to

Re: Direct proxies strawman

> >> We could even allow for direct proxies to acquire non-standard internal >> properties from their target object. This could be a useful principle when >> wrapping host objects. > > This seems important in order to make host methods work, e.g., the ones that > access the [[Value]] property.

Re: Direct proxies strawman

There are other alternatives, such as supporting both alternatives with two different entry points (con: API proliferation), taking an optional boolean flag indicating to return the pair (con: too dynamic a type), taking an optional outparam object (con: what is this? C?). OK, so most of those

Re: decoupling [ ] and property access for collections

uot; is to pass the name as a string. Yes, there's a certain aesthetic that says that's icky, but JS makes it so convenient that it's the obvious thing to do. Dave On Oct 17, 2011, at 4:15 PM, Allen Wirfs-Brock wrote: > > On Oct 17, 2011, at 3:34 PM, David Herman wrote: >&

Re: Rationale for dicts?

> I do not yet fully understand the rationale behind dicts. Nothing fancy, really. Just an idiomatic way to create a non-polluted string-to-value map. In ES5 you can use Object.create(null), which is not bad but still kind of a hack. Wouldn't it be nice to have sweet literal syntax for a dictio

Re: decoupling [ ] and property access for collections

> (Dave Herman has another way to say this: [ ] and . can be viewed as > operating on two separate property name spaces, but for legacy/normal ES > objects those namespaces are collapsed into a single shared namespace.) Lest the above be construed as a tacit approval on my part... ;) > IMHO th

Re: Direct proxies strawman

Hi Tom, this looks very promising. Some comments below; quoting the wiki page inline. > * target is the object which the direct proxy wraps Just checking: presumably this proposal doesn't allow for target to be a primitive, right? (Other than the special case of null you mention later.) I.e.,

Re: proxies: stratifying toString, valueOf

> I agree with Andreas. The implicitly-called base level methods are not > meta-methods or (spec language) "internal methods". They do not need their > own traps. They are base-level property accesses. Well, certainly that's the way the language currently works. But the way it currently works i

Re: proxies: stratifying toString, valueOf

> If you want to stratify toString/valueOf in general and for all objects, I > would very much support that. I'm not sure I understand what you mean. Do you mean something like: js> var obj = Object.create(null, {}); js> String(obj) TypeError: can't convert obj to string js> Obje

Re: proxies: receiver argument and object maps

other message I sent this afternoon. (Well, that and performance, which quite possibly sucks. So this may not be a viable idea. It was an interesting experiment, anyway.) Dave On Oct 16, 2011, at 2:49 PM, David Bruant wrote: > Le 16/10/2011 23:02, David Herman a écrit : >> Forgive me that

Re: proxies: receiver argument and object maps

D'oh -- of course, you're right. The use case I'm describing wants the proxy, not the receiver. Thanks, Dave On Oct 16, 2011, at 2:44 PM, David Bruant wrote: > Le 16/10/2011 23:02, David Herman a écrit : >> Forgive me that I've not kept track of where we are in

proxies: receiver argument and object maps

Forgive me that I've not kept track of where we are in the discussion about the additional receiver argument. I think I just found a pretty important use case for the receiver argument. Say you want to keep some information about a proxy object in a Map or a WeakMap, and you want the handler to

Re: proxies: stratifying toString, valueOf

trying: valueOf trying: toString TypeError: can't convert obj to primitive type Dave On Oct 16, 2011, at 1:46 PM, David Herman wrote: > If you want to create a clean-slate proxy object -- for example, a dictionary > -- then you can't predefine toString or valueOf. But this

proxies: stratifying toString, valueOf

If you want to create a clean-slate proxy object -- for example, a dictionary -- then you can't predefine toString or valueOf. But this means your object will always fail at the semantic operations [[ToString]] and [[ToPrimitive]]. For example: > var obj = Proxy.create(myEmptyHandler, proto

Re: Harmony transpilers

s. How so? You can expressive the former as sugar for the latter, but not vice versa. Dave On Oct 11, 2011, at 8:00 PM, John J Barton wrote: > > > On Tue, Oct 11, 2011 at 6:17 PM, David Herman wrote: > > Traceur is very good! I'd just like to have something that com

Re: Harmony transpilers

> Traceur is very good! I'd just like to have something that compiles to ES5 > without intermediate libraries, the way CoffeeScript works, so that it's > easier to debug and use in NodeJS. You aren't going to be able to match CoffeeScript's readability for many features, especially generators,

Re: Harmony transpilers

I have some thoughts about how to use Narcissus as a basis for a compiler to ES3 as well. It's obviously not necessary to do separately from Traceur, but it might be interesting to experiment with alternative implementation strategies. I haven't really done anything in earnest yet, including loo

Re: holes in spread elements/arguments

I don't think we can get away with repurposing _ as a pattern sigil, since it's already a valid identifier and used by popular libraries: http://documentcloud.github.com/underscore/ In my strawman for pattern matching, I used * as the "don't-care" pattern: http://wiki.ecmascript.org/dok

Re: {Weak|}{Map|Set}

I mostly have a similar approach in mind for tail calls. Precise about the interface, imprecise/informative about the implementation requirements. For WeakMaps, that means a well-defined API with informal English describing the expectations about memory consumption. For tail calls, it means a we

Re: Grawlix

On this particular issue, I'm inclined to agree -- I think we should be extremely sparing with how many new sigils, if any, we introduce into the language. You'll notice Brendan has repeatedly said similar things about <| and .{ for example. Syntax matters. But I feel like now might be a good t

Re: Bug: String.prototype.endsWith

Fixed, thanks. Dave, digging his way out of a massive backlog... On Sep 23, 2011, at 12:18 PM, Axel Rauschmayer wrote: > http://wiki.ecmascript.org/doku.php?id=harmony:string_extras > I’ve found a small bug: > > String.prototype.endsWith = function(s) { > var t = String(s); > return thi

Re: Enums?

A couple reactions: - strings are already interned in current engines for symbol-like performance; there's no need to introduce symbols into the language - private names are overkill for most uses of enums; just use string literals - in SpiderMonkey I think you get better performance if your sw

Re: Sep 27 meeting notes

bject: Re: Sep 27 meeting notes >> Date: September 30, 2011 23:17:04 GMT+02:00 >> To: Brendan Eich >> Cc: es-discuss , Erik Arvidsson >> >> >> Without 2, 4, and 5, object initializers are close enough to make having an >> extra class facility not carry it

Re: Generalization of destructuring assignment, has this been discussed before?

I've never liked these kinds of proposals because they confuse the declarative and imperative. Binding is static in JS (usually, anyway), and destructuring binding is a static form. If you introduce dotted forms you turn what looks like a binding form into purely a data-structure-mutating operat

Re: Object.{getPropertyDescriptor,getPropertyNames}

by searching -- worked!) > > /be > > On Sep 2, 2011, at 3:33 PM, David Herman wrote: > >> Object.getPropertyDescriptor > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Object.{getPropertyDescriptor,getPropertyNames}

The proxies page refers to Object.getPropertyDescriptor and Object.getPropertyNames as the obvious operations that they ought to be, but also points out that they aren't in ES5. Is there a part of the wiki specs that explicitly state that they should be included in ES6? If not, we all agree the

Re: Clean scope

> Mozilla has evalInSandbox built-ins. We've talked about them, but no one has > produced a strawman based on this work. The module loader API: > > http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders > > provides enough functionality. In fact, I think "sandbox" is a pretty good intuit

Re: private name objects confusion

> Yep. Sorry, editing snafu -- I'd started to call it a non-issue when it > occurred to me that proxy authors would still have to know not to string > coerce keys. No big deal -- proxy authors should know better than to rely on > es5 invariants. Agreed. > Throw at the point where a unique name

Re: private name objects confusion

> Understood WRT the forgeability of strings -- I was more concerned with the > potential hazard of toStringing the values of an own-names array, only to > find out you have several keys with the string value "undefined". Sure you're > doing it wrong, but string keys are an es5 invariant -- it's

Re: private name objects confusion

> I've been exploring private name objects [1] and I'm a bit confused by a few > things in the proposal, especially the Reflection example... The page was out of date, sorry. I've updated the page to reflect the agreement we came to in the last face-to-face, which was that private names should n

Re: Feedback on Binary Data updates

Hi Luke, The idea is definitely to subsume typed arrays as completely as possible. > * Array types of fixed length > The current design fixes the length of an ArrayType instance as part of the > ArrayType definition, instead of as a parameter to the resulting constructor. > I'm not sure I unde

Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)

Putting private properties on a proxy or storing it in a weak map are simple protocols you can use to keep track of proxies that you know about. You can hide or expose this information then without however many or few clients you like. If you want to give people access to knowledge about your pr

Re: Design principles for extending ES object abstractions

> My understanding of generators was naively that they are syntactic sugar for > defining an iterator. Well, I think I understand what you're getting at: there's a sense in which generators don't add the ability to do something that's *absolutely impossible* to express in ES5. OTOH, generators

Re: using Private name objects for declarative property definition.

> I'm not so sure about this now. I was just reviewing with Dave how the design > evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs, > Dave had thought he had a use-case where the code has a function and wants to > know whether it's a generator. It turned out (IIUC) th

Re: using Private name objects for declarative property definition.

>> Adding a non-enumerable Array.prototype method seems doable to me, if the >> name is clear and not commonly used. > > > We can probably still add Array.prototoype.isArray if that would help to > establish the pattern. Document as being preferred over Array.isArray This doesn't make sense to

Re: module exports

ntent. > > On Jul 10, 2011, at 8:11 PM, David Herman wrote: > >>> According to the module grammar, the following is valid: >>> >>> 691module car { >>> function startCar() {} >>> module engine { >>> function start() {} >&

Re: Extending standard library of arrays

> My point is that the map spec is a deterministic algorithm because > side-effects would be noticeable otherwise. However, this prevent > implementations where function calls would be done in parallel for instance > (for better performances). In some cases (like the one I showed), the exact >

Re: module exports

> According to the module grammar, the following is valid: > > 691module car { > function startCar() {} > module engine { > function start() {} > } > export {start:startCar} from engine; > } > > > It seems like there would be issues with exporting module elements after the > module

Re: Array generation

Agreed. I think that's a pretty common way people think about null vs undefined, and it's consistent with the language's behavior. Dave On Jul 10, 2011, at 3:09 PM, liorean wrote: > On 10 July 2011 22:23, David Herman wrote: >> Another common and useful fusion of two t

Re: Design principles for extending ES object abstractions

>> I'm not sure what Array.prototype methods would or wouldn't work on >> instances of SubArray. > > All of them. They are all generic. We're speaking too broadly here. It depends on what we want to work how. For example, .map can't magically know how to produce a SubArray as its result if th

Re: Array generation

>a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res > !== void 0)] > > I rather arbitrarily chose to accept both null and undefined here as way to > say "no element" -- a reasonable alternative would be to accept *only* > undefined as "no element". Oops, I meant to s

Re: Pure win: Array.from and Array.of

I mentioned two benefits I can see to Array.of over []-literals here: https://twitter.com/#!/littlecalculist/status/89854372405723136 1) With Array.of you know you aren't going to accidentally create holes, and 2) if you're passing it to a higher-order function you know you aren't going to

Re: Array generation

> So from this viewpoint (and regarding that example with squares), it's good > to have also `Array.seq(from, to)` method (the name is taken from Erlang, I > just frequently uses lists:seq(from, to) there): Array.range seems like an intuitive name as well. > Array.seq(1, 5).map((x) -> x * x); [

Re: Design principles for extending ES object abstractions

I think I still haven't fully grokked what <| means on array literals, but could it also be used to "subclass" Array? For example: function SubArray() { return SubArray.prototype <| []; } SubArray.prototype = new Array; I'm not sure what Array.prototype methods would or woul

Re: Design principles for extending ES object abstractions

> I agree wholeheartedly with these. In fact, I’d go further on (2), and > say “Anything that can be done declaratively can also be done > imperatively, using ES5 syntax”. > > >>The problem here is that some new syntax cannot be faked with old syntax, > >>namely function calls,

Re: Type of property names, as seen by proxy traps

And just to be clear, I meant produce in the sense of producer/consumer relationship on the trap functions, not in the generative sense. Dave On Jul 8, 2011, at 8:40 AM, David Herman wrote: > Sorry, yes. Too early in the morning for me. :) > > Indeed, handler traps are exactly the pl

Re: Type of property names, as seen by proxy traps

20 AM, Brendan Eich wrote: > On Jul 8, 2011, at 7:17 AM, David Herman wrote: > >>> The proposal does mention: "All reflective operations that produce a >>> property name, when reflecting on a private name, produce the name’s >>> .public property instead of the

Re: Type of property names, as seen by proxy traps

> I'm not sure. I briefly checked the private names proposal > and I > think the detailed interaction with proxies still has to be fleshed out. Sure, I'll be happy to work with you on this. > The proposal does mention: "All r

Re: Type of property names, as seen by proxy traps

> 2011/7/6 Andreas Rossberg > While putting together some test cases for Object.keys, I wondered: is > it intended that property names are always passed to traps as strings? > > That is indeed the intent. Unless they are private name objects, right? Dave ___

Re: JavaScript parser API

> Ah, sorry. Seems I got the wrong impression from the list archives - perhaps > only the interested parties participated in > those older threads. Thanks for clarifying. I think you're looking for a thumbs-up/thumbs-down answer from TC39, when we haven't really discussed it that much. We've exp

Re: JavaScript parser API

>>> - it is biased towards evaluation, which is a hindrance for other >>> uses (such as faithful unparsing, for program transformations); >> >> It's just a reflection of the built-in SpiderMonkey parser, which was >> designed for the sole purpose of evaluation. I didn't reimplement a >> new

Re: JavaScript parser API

> the AST API strawman - given the positive discussions on this list, I > thought the idea was implicitly accepted last year, modulo details, > so I was surprised not to see a refined strawman promoted. It hasn't really been championed so far. I was concentrating on other proposals for ES.next.

Re: Module grammar

Thanks-- missed one when manually doing s/ImportPath/ImportBinding/g. Fixed. Thanks, Dave On Jul 1, 2011, at 9:55 AM, Kam Kasravi wrote: > Should this > > ImportDeclaration(load) ::= "import" ImportBinding(load) ("," > ImportBinding(load))* ";" > ImportPath(load) ::= ImportSpecifierSet "from"

<    1   2   3   4   5   6   7   8   >