Re: An array destructing specification choice

On Nov 11, 2011, at 5:06 PM, David Herman wrote: > On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote: > >> ... >> We currently haven't specified this syntactic form. I'm not sure if it adds >> enough value to justify the added conceptual complexity. > > I think it's a pretty big win, and I

Re: An array destructing specification choice

On Nov 11, 2011, at 5:06 PM, David Herman wrote: > Also: we'll definitely want to allow it for splicing, s/splicing/spread/ /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Minimalist (why) classes ?

On Nov 11, 2011, at 5:02 PM, Irakli Gozalishvili wrote: > What I'm suggesting is to sugar Sugar usually means new syntax, not methods, but no worries. > current patterns, without adding new syntax similar to how > Funciton.prototype.bind was added. That ES5 addition was years late, a bit dif

Re: Using monocle mustache for chaining.

While I was admiring the pros of its mutation, I overlooked how unclear it was that a mutation was even occurring... Anyway, thanks for the clarification. /Rick On Nov 11, 2011, at 8:22 PM, David Herman wrote: > On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote: > >> Dave, if nesting were out

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: Minimalist (why) classes ?

On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eich wrote: > On Nov 11, 2011, at 4:42 PM, John J Barton wrote: > >> Object.extend() does not exist. > > Which one do you mean? I mean Object.extend does not exist. > > Irakli is using Function.prototype.extend, not something like PrototypeJS's > Object.

Re: An array destructing specification choice

>>> [a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0] >> >> We currently haven't specified this syntactic form. I'm not sure if it adds >> enough value to justify the added conceptual complexity. > > I think it's a pretty big win, and I'd argue it's totally intuitive. The > great thing about destructu

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]; >> 〰〰 >> ak = %v[k]; >> let %length = %v.length; > > do we sample the

Re: Minimalist (why) classes ?

What I'm suggesting is to sugar current patterns, without adding new syntax similar to how Funciton.prototype.bind was added. And maybe in next iteration add special syntax if it still we be wanted. It's just so much easier to fix `Object.extend` if it will end up to be a wrong fit than change a

Re: Minimalist (why) classes ?

On Nov 11, 2011, at 4:42 PM, John J Barton wrote: > Object.extend() does not exist. Which one do you mean? Irakli is using Function.prototype.extend, not something like PrototypeJS's Object.extend. > Similar but not identical functions > are widely used. We would like a standard form built-in

Re: Minimalist (why) classes ?

On Fri, Nov 11, 2011 at 4:31 PM, Brendan Eich wrote: > On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote: > > Thats exact port of proposal that Jeremy wrote here: > https://gist.github.com/1329619 > I could write add examples from the classes proposal if that wolud help: > http://wiki.ecmascr

Re: Minimalist (why) classes ?

On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote: > Thats exact port of proposal that Jeremy wrote here: > https://gist.github.com/1329619 > > I could write add examples from the classes proposal if that wolud help: > http://wiki.ecmascript.org/doku.php?id=harmony:classes Maybe, but I thi

Re: An array destructing specification choice

>> A pattern of the form >> >> [a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0] > > We currently haven't specified this syntactic form. I'm not sure if it adds > enough value to justify the added conceptual complexity. Using this pattern for accessing elements at the end would be useful. For exam

Re: Using monocle mustache for chaining.

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. /Rick On Nov 11, 2011, at 3:13 PM, David Herman wrote: > On Nov 11, 2011, at 10:50 AM, Erik Arvidsso

Re: Minimalist (why) classes ?

Thats exact port of proposal that Jeremy wrote here: https://gist.github.com/1329619 I could write add examples from the classes proposal if that wolud help: http://wiki.ecmascript.org/doku.php?id=harmony:classes Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Sai

Re: Subclassing an array and array methods

On Nov 11, 2011, at 11:07 AM, Allen Wirfs-Brock wrote: > On Nov 11, 2011, at 10:52 AM, Axel Rauschmayer wrote: > >> Got it, related to what you solve in generic classes with This-types >> (covariance vs. contravariance...). >> >> // assume |this| is the source collection >> if (this[Array.d

Re: WeakMaps question ?

On Nov 11, 2011, at 3:39 PM, Oliver Hunt wrote: > A weak map can only remove an entry if both the key and value have died, in > many ES implementations a number of the primitives are not gc allocated and > so can never die, or are cached globally so have lifetime unrelated to any > given progr

Re: WeakMaps question ?

I think what I need is a map with primitive keys and non-null object values, entries of which can be removed & GC-ied if values are no longer referenced. If I understand Map / Set / WeakMap proposals non of them can be used to solve this issue or do I miss something ? Regards -- Irakli Gozalis

Minimalist (why) classes ?

Hi, I have posted this to the long thread of "Minimalist Classes", but since I have not got any response, I assume it got lost into a long discussion. So I thought I'll give it another try on fresh thread. I do really liked direction that Jeremy tried to push classes to, but still I don't und

Re: (Almost) everything is expression

On Nov 11, 2011, at 10:25 AM, gaz Heyes wrote: > On 11 November 2011 18:01, Dmitry Soshnikov > wrote: > var foo = { > // do stuff > 100; > }; > > What would be the result of a labelled statement? You'd need labels to work > within expressions since you'd probably want to do: > x=loop:for(i=0

Re: (Almost) everything is expression

On Nov 11, 2011, at 10:22 AM, gaz Heyes wrote: > On 11 November 2011 17:13, David Herman wrote: > Your idea of mandatory parens is still valid (if, IMO, a bit unsatisfyingly > verbose) for most statement forms. It's only the block-statement-expression > that doesn't work. Hence my do-expression

Re: WeakMaps question ?

A weak map can only remove an entry if both the key and value have died, in many ES implementations a number of the primitives are not gc allocated and so can never die, or are cached globally so have lifetime unrelated to any given program. The net effect of allowing such primitive values to b

Re: (Almost) everything is expression

On Nov 11, 2011, at 9:49 AM, Mark S. Miller wrote: > On Fri, Nov 11, 2011 at 9:13 AM, David Herman wrote: > [...] > Hence my do-expressions: > > http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions > > or Brendan's subtly-disambiguated-block-statement-expressions: > > http:

Re: WeakMaps question ?

On Fri, Nov 11, 2011 at 3:28 PM, Irakli Gozalishvili wrote: > I really need to know why WeakMaps don't accept primitives as keys, can > anyone please reply ? It’s because WeakMaps are intended to drop values if the key is garbage collected. A WeakMap guarantees that it will drop its value if it

Re: An array destructing specification choice

On Nov 11, 2011, at 3:17 PM, David Herman wrote: > 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 patte

Re: WeakMaps question ?

Irakli Gozalishvili wrote: I really need to know why WeakMaps don't accept primitives as keys, can anyone please reply ? How would the GC know when to remove the entry from the map? Because a primitive is never (or always, if wrapped) eligible for garbage-collection, a WeakMap does not help y

Re: An array destructing specification choice

On Nov 11, 2011, at 3:17 PM, David Herman wrote: > 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 patter

Re: WeakMaps question ?

I really need to know why WeakMaps don't accept primitives as keys, can anyone please reply ? Thanks! -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu) On Thursday, 2011-11-10 at 10:31 , Irakli Gozalishvili wrot

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

2011/11/11 David Herman : > 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 propos

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'd say. >> Sorry, that was an (American?) English colloqu

Re: Preventing instance extension

> And why can't you call the superconstructor at the end? > It'd work the exact same except it could overwrite some of the > properties you wrote... but since those things would more likely be in > prototype, it's not much of an issue. That is definitely a possibility! It does have one drawback,

Re: Preventing instance extension

And why can't you call the superconstructor at the end? It'd work the exact same except it could overwrite some of the properties you wrote... but since those things would more likely be in prototype, it's not much of an issue. On Fri, Nov 11, 2011 at 10:05 PM, Juan Ignacio Dopazo wrote: >> On Fr

Re: Preventing instance extension

> > On Fri, Nov 11, 2011 at 4:23 PM, Xavier MONTILLET > wrote: > Object.getPrototypeOf(this) === Point.prototype <=> this instanceof Point > > Actually, no. this instanceof Point => Object.getPrototypeOf(this) === Point.prototype, but not the other way around. > And I don't understand your probl

Re: (Almost) everything is expression

On 11.11.2011 23:44, David Herman wrote: 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!" And what does it mean? :) I translated it as "how do you like it, a

Re: Using monocle mustache for chaining.

On Fri, Nov 11, 2011 at 11:38, Oliver Hunt wrote: > But ignoring that, the decision we made at last november's meeting was that > DOM attributes would be specified as setters on the prototype, so > > someElement.style.{background:"blue", border: "2px solid black"} > > would add to own properties

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: Object.getOwnPropertyDescriptors

It has already been proposed, look here: http://wiki.ecmascript.org/doku.php?id=strawman:extended_object_api On Nov 11, 2011, at 20:30 , Xavier MONTILLET wrote: > Hi, > > I think adding Object.getOwnPropertyDescriptors would be great. > > It could be implemented like this: > > Object.getOwnPr

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: Using monocle mustache for chaining.

On Fri, Nov 11, 2011 at 11:27, Luke Hoban wrote: > > > document.querySelector('#my-element').{ > >   style.{ > >    'color': 'red', > >    'padding': '5px' > >  }. > >  textContent: 'Hello' > > }; > > I don't think I've seen this form of the .{ syntax discussed before.   Is an > expression being

Re: Using monocle mustache for chaining.

I'm sorry, i don't understand the semantics you're going for here. What is document.querySelector('#myTable').{ querySelectorAll('.firstColumn').{ style.{background: 'red', border: '2px solid black'}, textContent: 'first column' }, querySelectorAll('.lastColumn').{ style.{backgr

Re: Using monocle mustache for chaining.

It appears to be assigning multiple properties in place and at once and returning the original object if I am understanding correctly. On Fri, Nov 11, 2011 at 1:27 PM, Luke Hoban wrote: > > document.querySelector('#my-element').{ > > style.{ > >'color': 'red', > >'padding': '5px' > >

Re: Using monocle mustache for chaining.

For some reason, the code in the original most formatted with a lot of vertical white space in my mailer. I tried to fix it below: 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 i

Object.getOwnPropertyDescriptors

Hi, I think adding Object.getOwnPropertyDescriptors would be great. It could be implemented like this: Object.getOwnPropertyDescriptors = function ( object ) { var propertiesDescriptor = { }; Object.getOwnPropertyNames( object ).forEach( function ( key ) { propertiesDescriptor[ k

RE: Using monocle mustache for chaining.

> document.querySelector('#my-element').{ > style.{ >'color': 'red', >'padding': '5px' > }. > textContent: 'Hello' > }; I don't think I've seen this form of the .{ syntax discussed before. Is an expression being used as the LHS of an object literal property assignment? What does "

Re: Preventing instance extension

Object.getPrototypeOf(this) === Point.prototype <=> this instanceof Point And I don't understand your problem >_ < On Fri, Nov 11, 2011 at 8:11 PM, Axel Rauschmayer wrote: > Having recently bitten by a mistyped property name (see code underneath > signature), I think I might prevent the extensi

Preventing instance extension

Having recently bitten by a mistyped property name (see code underneath signature), I think I might prevent the extension of instances more often. But what is the best way of doing so? Variant 1: prevents subtyping the constructor function Point(x, y) { this.x = x; this.y =

Re: Subclassing an array and array methods

On Nov 11, 2011, at 10:52 AM, Axel Rauschmayer wrote: > Got it, related to what you solve in generic classes with This-types > (covariance vs. contravariance...). > >// assume |this| is the source collection >if (this[Array.derivedArrayKey]) A = this[Array.derivedArrayKey](); else A >

Re: (Almost) everything is expression

On 11.11.2011 22:48, gaz Heyes wrote: On 11 November 2011 18:29, Dmitry Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: This is why the topic is called "*(Almost)* everything...". In general case we may not include this case with label-statement into proposal, since the constru

Re: Subclassing an array and array methods

Got it, related to what you solve in generic classes with This-types (covariance vs. contravariance...). // assume |this| is the source collection if (this[Array.derivedArrayKey]) A = this[Array.derivedArrayKey](); else A = [ ]; Another possibility: if (this[Array.derivedArrayKey])

Using monocle mustache for chaining.

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. However, I (with some help) realized that the .{ operator can be used to solve most of t

Re: (Almost) everything is expression

On 11 November 2011 18:29, Dmitry Soshnikov wrote: > This is why the topic is called "*(Almost)* everything...". In general > case we may not include this case with label-statement into proposal, since > the construction you wrote isn't practice IMO. But, we should consider also > theoretical thin

Re: Strawman: Decouple [ ] and property access

+1 !! On Nov 11, 2011, at 10:02 AM, Erik Arvidsson wrote: > I implemented this for Traceur last week. The abstraction is leaky > since Traceur does not have private names yet but it is still good > enough for a demo. > > http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html __

Re: (Almost) everything is expression

On 11.11.2011 22:25, gaz Heyes wrote: On 11 November 2011 18:01, Dmitry Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: var foo = { // do stuff 100; }; What would be the result of a labelled statement? You'd need labels to work within expressions since you'd probably w

Re: Subclassing an array and array methods

On Nov 11, 2011, at 9:47 AM, Axel Rauschmayer wrote: >> function createArraySubclass(proto,...values) { >> return proto <| [...values].{ >> [Array.derivedArrayKey](){return proto<| [ ]} >> } >> } > > I’m curious: Why wouldn’t one extend Array, instead? the problem is with built-ins

Re: (Almost) everything is expression

On 11.11.2011 21:13, David Herman wrote: 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 mailto:erig...@google.com>> wrote: let a = ({ prin

Re: (Almost) everything is expression

On 11 November 2011 18:01, Dmitry Soshnikov wrote: > var foo = { > // do stuff > 100; > }; > What would be the result of a labelled statement? You'd need labels to work within expressions since you'd probably want to do: x=loop:for(i=0;i<10;i++){ } but then what if you do: x=1/loop:for(i=0;i<1

Re: (Almost) everything is expression

On 11 November 2011 17:13, David Herman wrote: > Your idea of mandatory parens is still valid (if, IMO, a bit > unsatisfyingly verbose) for most statement forms. It's only the > block-statement-expression that doesn't work. Hence my do-expressions > It should also apply to function expressions I

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: Strawman: Decouple [ ] and property access

I implemented this for Traceur last week. The abstraction is leaky since Traceur does not have private names yet but it is still good enough for a demo. http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html Instead of private names we just use Object.define* On Fri, Nov 11, 20

Re: (Almost) everything is expression

On 11.11.2011 20:36, Brendan Eich wrote: On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote: 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. No, it is a runtime incompatibility that shift

Re: (Almost) everything is expression

On Nov 11, 2011, at 9:13 AM, David Herman wrote: > 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 th

Re: (Almost) everything is expression

On Fri, Nov 11, 2011 at 9:13 AM, David Herman wrote: [...] > Hence my do-expressions: > > http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions > > or Brendan's subtly-disambiguated-block-statement-expressions: > > > http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_li

Re: Subclassing an array and array methods

> function createArraySubclass(proto,...values) { >return proto <| [...values].{ > [Array.derivedArrayKey](){return proto<| [ ]} >} > } I’m curious: Why wouldn’t one extend Array, instead? function SubArray() { } SubArray.prototype = Object.create(Array.prototype); SubArray.proto

Re: (Almost) everything is expression

On Nov 11, 2011, at 7:39 AM, Neil Eades wrote: > On 11 November 2011 15:33, Mark S. Miller wrote: > Insist on enclosing parens, since > "(" introductory-token > is not otherwise legal > > let a = ({ > > print('doing stuff'); > 100; > }); > > Even the last is now easily unambiguous. > >

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: Strawman: Decouple [ ] and property access

That the [] decoupling is needed can by seen by the fact that dicts can’t have a size() method (as opposed to the dictionary solution in the strawman). On Nov 11, 2011, at 17:45 , Allen Wirfs-Brock wrote: > thanks, a good suggestion. > > Actually they are quite different. The dict proposal is

Re: (Almost) everything is expression

On Nov 11, 2011, at 2:52 AM, Axel Rauschmayer wrote: >> which I thought could be turned into: >> - >> var C = { >> let something; >> >> // |this| is the global object >> // ... >> } >> - >> >> But it does not have a return value and as noted in your second message, >> there seems

Re: Strawman: Decouple [ ] and property access

thanks, a good suggestion. Actually they are quite different. The dict proposal is simply defining one new data types that can be used as a key value store which is guaranteed not to have any pre-existing key conflicts prior to initial use. My proposal, defines a general extensible mechanism

Re: (Almost) everything is expression

On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote: > 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. No, it is a runtime incompatibility that shifts meaning, without errors. switch (x

Re: Subclassing an array and array methods

My intent is to use a private name property to allow an object to provide a constructor for new "arrays" derived" from it. something along the lines of: function createArraySubclass(proto,...values) { return proto <| [...values].{ [Array.derivedArrayKey](){return proto<| [ ]} } }

Re: (Almost) everything is expression

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 literal? Surely it becomes an expression o

Re: (Almost) everything is expression

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 literal? Surely it becomes an expression once an assignment occurs anyway. __

Re: (Almost) everything is expression

On 11 November 2011 15:33, Mark S. Miller wrote: > Insist on enclosing parens, since > "(" introductory-token > is not otherwise legal > > let a = ({ >> >> print('doing stuff'); >> 100; >> }); >> > > Even the last is now easily unambiguous. > > And is this not clearer than let a = {|| prin

Re: (Almost) everything is expression

Insist on enclosing parens, since "(" introductory-token is not otherwise legal > let a = (switch (foo) { > case 10: 100; > default: 200; > }); > > 2. If-expression: > > let a = (if (foo) { > print('a is foo'); > foo; > } else { > // do some longer stuff > }); > > > 3. Try-expressions: > >

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

Subclassing an array and array methods

In es-next we should be able to subclass an array function createArraySubclass(proto, ...values) { return proto <| [...values]; } However when we call `instanceOfSubArray.filter(...)` this method returns a new Array rather then a new SubArray. It would seem frustrating to have to overwrite al

Re: (Almost) everything is expression

2011/11/11 David Herman : >> 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

Re: supporting ES upgrading with a programming pattern repo?

To keep this thread from getting off-track: I am talking about patterns as a common ground between ES.next spec writers and JS.current coders. Focusing on patterns now would help to get JS coders involved in checking current proposals for consistency/edge cases, instead of leaving that burden to

Re: (Almost) everything is expression

On 11.11.2011 16:03, gaz Heyes wrote: 11/11/2011 08:07, Dmitry Soshnikov : Hi, (unfortunately Twitter is again doesn't fit for a more than 140 ch discussion, so moving here) I'd like to still notice the possibility of accepting the "almost everything is

Re: (Almost) everything is expression

On 11 November 2011 12:48, François REMY wrote: > I think you strongly underestimate the "distinction" problem. It's *not* > possible to make any difference between the "foo" statement and the "print" > statement of your sample, from the compiler point of view. Why would the > "foo" statement be t

Re: (Almost) everything is expression

On 11.11.2011 15:48, François REMY wrote: I think you strongly underestimate the "distinction" problem. It's *not* possible to make any difference between the "foo" statement and the "print" statement of your sample, from the compiler point of view. Why would the "foo" statement be the one chos

Re: (Almost) everything is expression

11/11/2011 08:07, Dmitry Soshnikov : > Hi, >> >> (unfortunately Twitter is again doesn't fit for a more than 140 ch >> discussion, so moving here) >> >> I'd like to still notice the possibility of accepting the "almost >> everything is expression" approach for JS. After Erlang I very often miss >

Re: (Almost) everything is expression

I think you strongly underestimate the "distinction" problem. It's *not* possible to make any difference between the "foo" statement and the "print" statement of your sample, from the compiler point of view. Why would the "foo" statement be the one chosen as a return value for the "if" block? It

Re: (Almost) everything is expression

>> IIRC: Block lambdas. >> >> var C = {|| // note the double pipe >>let something; >> >>// |this| is the global object >>// ... >> >>return something; >> } >> > > This contradicts TCP though. E.g. Ruby supports it and there we can't > `return` from blocks, since block wrappi

Re: (Almost) everything is expression

On 11.11.2011 14:52, Axel Rauschmayer wrote: which I thought could be turned into: - var C = { let something; // |this| is the global object // ... } - But it does not have a return value and as noted in your second message, there seems to be an ambiguity with object initia

Re: (Almost) everything is expression

On 11.11.2011 14:44, François REMY wrote: I didn't read your first mail, I've to acknowledge. That doesn't change the fact the sample was reinventing the wheel. I still don't see how your this sentence helps taking into account that I myself noted this case, sorry. BTW,your samples all suf

Re: (Almost) everything is expression

On 11.11.2011 14:37, David Bruant wrote: Hi, It reminds me of something I was thinking about recently. A very common pattern in JS is: (function(global){ var private1 = 'a'; // ... global.something = 11; })(this) block-scoped variables allow a light-weigth version of this patter

Re: (Almost) everything is expression

> which I thought could be turned into: > - > var C = { >let something; > >// |this| is the global object >// ... > } > - > > But it does not have a return value and as noted in your second message, > there seems to be an ambiguity with object initializers (not only visual bu

Re: (Almost) everything is expression

I didn't read your first mail, I've to acknowledge. That doesn't change the fact the sample was reinventing the wheel. BTW,your samples all suffer from a big ambuiguity that I think is unresolvable. let a = if (foo) { print('a is foo'); foo; } else { // do some longer

Re: (Almost) everything is expression

Hi, It reminds me of something I was thinking about recently. A very common pattern in JS is: (function(global){ var private1 = 'a'; // ... global.something = 11; })(this) block-scoped variables allow a light-weigth version of this pattern: - { let private1 = 'a'; // |th

Re: (Almost) everything is expression

On 11.11.2011 13:26, François REMY wrote: let x = q ? 10 : 20; Why we're reinventing the wheel here is up to me. I noted it in the initial letter. Yes, we have the sugar for this particular case for years (the ternary operator). But also with this I mention that it doesn't allow _

Re: (Almost) everything is expression

let x = q ? 10 : 20; Why we're reinventing the wheel here is up to me. -Message d'origine- From: Dmitry Soshnikov Sent: Friday, November 11, 2011 8:54 AM To: David Herman Cc: es-discuss Steen Subject: Re: (Almost) everything is expression On 11.11.2011 11:43, David Herman wr