Re: Converting strings to template strings

[Kyle Simpson]

I've dubbed them "Interpolated String Literals" (or "Interpolated Strings") in 
my writings and materials going forward. I mention "Template Literals" and then 
explain why it's a bad name.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Jordan Harband]

I don't believe test262 can yet be run in a browser (only directly against
a browser engine), nor run in ES3 browsers (so that shimmed engines can be
tested) so that doesn't yet solve my use cases, although I can't speak for
Kyle.

On Wed, Mar 25, 2015 at 9:32 PM, James Kyle  wrote:

> This exists: http://test262.ecmascript.org
>
>
>
> On Wed, Mar 25, 2015 at 8:12 PM, liorean  wrote:
>
>> As I see it, what might be more desireable than a straight shallow
>> feature test or feature support reporting feature would be an official
>> versioned test library, possibly including tests of pure internals, and a
>> new standard api for asking the engine for the results it gets for running
>> a certain test or set of tests. The engine could then either have its
>> results collected at build time and cashed results for that particular
>> build built into the api, or allow the user to require the result of
>> getting the test and executing it live, with the issues that comes with
>> that. One possible result, except the obvious success and fail, is of
>> course that a certain test didn't exist at the time of the build and thus
>> not tested.
>>
>> Of course, the earliest something like that could be in the language
>> would be ECMAScript 7...
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[James Kyle]

This exists: http://test262.ecmascript.org

On Wed, Mar 25, 2015 at 8:12 PM, liorean  wrote:

> As I see it, what might be more desireable than a straight shallow feature
> test or feature support reporting feature would be an official versioned
> test library, possibly including tests of pure internals, and a new
> standard api for asking the engine for the results it gets for running a
> certain test or set of tests. The engine could then either have its results
> collected at build time and cashed results for that particular build built
> into the api, or allow the user to require the result of getting the test
> and executing it live, with the issues that comes with that. One possible
> result, except the obvious success and fail, is of course that a certain
> test didn't exist at the time of the build and thus not tested.
> Of course, the earliest something like that could be in the language would
> be ECMAScript 7...___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[liorean]

As I see it, what might be more desireable than a straight shallow feature
test or feature support reporting feature would be an official versioned
test library, possibly including tests of pure internals, and a new
standard api for asking the engine for the results it gets for running a
certain test or set of tests. The engine could then either have its results
collected at build time and cashed results for that particular build built
into the api, or allow the user to require the result of getting the test
and executing it live, with the issues that comes with that. One possible
result, except the obvious success and fail, is of course that a certain
test didn't exist at the time of the build and thus not tested.

Of course, the earliest something like that could be in the language would
be ECMAScript 7...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Always close iterators?

[Bergi]

Axel Rauschmayer schrieb:
wouldn’t the iteration protocol be simpler if iterators were always 

closed (versus only if iteration finishes abruptly)?

Hm, I can't see much harm in that, it seemd to simplify the 
implementation of iterators indeed. It changes the semantics from


| cleanup must be done before returning the iterresult

(that's how `finally` works) to

| after having returned the iterresult, you will be made to clean up

Or, actually, that doesn't sound as good. "Some will *hopefully* tell 
you" to clean up is not what looks like good, resilient design.


While it does indeed simplify the producer implementation, the consumer 
side does get more complicated - from


  for (let iter=getIterator(), value, done; {value,done}=iter.next(), 
!done; ) {

  console.log(value);
  // Assuming this never throws
  }

to

  let iter = getIterator();
  for (let value, done; {value,done}=iter.next(), !done; ) {
  console.log(value);
  // Assuming this never throws
  }
  iter.return(); // additional line required

Of course, if done properly (accounting for exceptions) the change is 
minimal - from try-catch to try-finally. But who does that, how often is 
it forgotten?


 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Always close iterators?

[Axel Rauschmayer]

>> Given that redundant calls to `return()` don’t make a difference (h/t Bergi)
> 
> I'm sorry, that was not 100% accurate.

Right, ignore that part of my email. My main argument is: “wouldn’t the 
iteration protocol be simpler if iterators were always closed (versus only if 
iteration finishes abruptly)?”

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Forwarding `return()` in generators

[Axel Rauschmayer]

>> Right. Always closing is much simpler. Otherwise, you’d have to check 
>> whether everything was exhausted or not.
> 
> This is by design, FWIW.

Which is OK, I’m more worried about generators behaving differently in reaction 
to `return()` than, e.g., array iterators. With the latter, you can continue 
iterating if you break from a `for-of` loop, with the former, you (generally) 
can’t. Either behavior is OK, but it should be consistent: Is `return()` for 
optional clean-up (array iterators) or does it really close an iterator 
(generators)?

The way that `return()` is handled in generators (via try-catch) means that the 
clean-up action is called in both cases: generator exhaustion and generator 
closure. If you don’t use a generator then a clean-up action in `return()` is 
only called if the iterator is closed, not if it is exhausted. Obviously that 
is a minor technical detail and easy to fix (call the clean-up action when you 
return `{ done: true }`), but it’s still an inconsistency (which wouldn’t exist 
if `return()` was called in either case).

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Expression Closures as Compliment to Arrow Functions

[Brendan Eich]

Isiah Meadows wrote:
Would this be rectifiable with something like an unbound lambda type 
syntax?


There's nothing to rectify -- could do m() expr; in classes as shorter 
form of m() { return expr; }, and similarly in object literals (, as 
separator, not ; as terminator).


What gates this concise body for method shorthand idea is strong sense 
it's worth the added complexity (syntax should be added only with clear 
and strong signal that it's needed, e.g. to provide a special form for 
new semantics that cannot be provided by an API). And then someone to do 
the work drafting an ES7 proposal.


What stopped thin-arrow function syntax when I got fat-arrow through 
TC39 was the idea that two arrows was a bridge too far. That sense might 
change with time user demand, but it's not something to rush. Anyway, 
thin arrow is not related to this thread.


You could even make an analogous equivalent for classes. 


Sure, but why require thin arrow for method shorthand, when method 
requires unbound `this`? Allowing fat arrow seems a hazard with no real 
use case motivating it. In any case, grammatically we need no arrow at 
all. There's no grammar issues AFAICS with concise methods of the m() 
expr; form, provided expr is parsed as an AssignmentExpression and ; is 
required.


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

Re: Forwarding `return()` in generators

[Brendan Eich]

Axel Rauschmayer wrote:
Right. Always closing is much simpler. Otherwise, you’d have to check 
whether everything was exhausted or not.


This is by design, FWIW.

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

Re: Supporting feature tests directly

[James Kyle]

The problem with that is you're still delegating to build tools and servers to 
solve the entire problem. As you said previously you would not opt for the 
pure-javascript solution:




```

if (Reflect.supports('TCO')) { /* recursive */ } else { /* not recursive */ }

```




So while I get the sentiment of "feature tests IN javascript", the problem (as 
you've said) is that your solution would not exist solely in your javascript.




In order for Reflect.supports to be practical it needs a build tool/server, but 
as soon as you introduce those better options are available.




I'm sorry that you'll have to think about it.

On Wed, Mar 25, 2015 at 3:14 PM, Kyle Simpson  wrote:

> We're getting way afield with this whole transpilers thing. I'll indulge it 
> for just this response, then I'll return my focus on this thread to the issue 
> at hand: feature tests IN javascript.
>> ...CSS. There was no way to do shallow testing so they added a way to do it.
> As I have repeatedly said, the intent is not to be able to do new sorts of 
> tests that are not currently possible.
> I know perfectly well that I can do `if (Array.prototype.includes) ..` tests 
> and I can also do `try { eval("(()=>{})") } catch..` tests. That's not new 
> news to anyone here.
> The intent is to take *only* the latter of those two and do it in a more 
> efficient and less hacky way.
>> Here's my ideal situation:
> Your "ideal situation" means that if I want split builds (I do!), I have to 
> maintain my transpiler's definitions and keep up to date on usage stats for 
> me site to decide when I care about a certain browser or when I stop caring 
> about it, and change my configurations accordingly. I know a lot of people 
> think that way. I most definitely do not. Pretty "not ideal" to me.
> I prefer an option where I can write and deploy code, and never touch it, or 
> even the server/tools, again (if I don't need to), and it will just continue 
> to work "forever". For awhile, tests will end up serving both files, but 
> eventually, as browsers evolve, the tests will all result in only the 
> *.es6.js files being served. To me, that's "ideal".
> In short, I don't actually want to think *at all* about what browsers do what 
> things. To whatever extent possible, I want feature tests to handle that 
> entirely. I think browser versions are meaningless arbitrary marketing 
> labels. caniuse data is, at best, amusement to me. I never make real 
> decisions based on it.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Kyle Simpson]

We're getting way afield with this whole transpilers thing. I'll indulge it for 
just this response, then I'll return my focus on this thread to the issue at 
hand: feature tests IN javascript.


> ...CSS. There was no way to do shallow testing so they added a way to do it.

As I have repeatedly said, the intent is not to be able to do new sorts of 
tests that are not currently possible.

I know perfectly well that I can do `if (Array.prototype.includes) ..` tests 
and I can also do `try { eval("(()=>{})") } catch..` tests. That's not new news 
to anyone here.

The intent is to take *only* the latter of those two and do it in a more 
efficient and less hacky way.


> Here's my ideal situation:

Your "ideal situation" means that if I want split builds (I do!), I have to 
maintain my transpiler's definitions and keep up to date on usage stats for me 
site to decide when I care about a certain browser or when I stop caring about 
it, and change my configurations accordingly. I know a lot of people think that 
way. I most definitely do not. Pretty "not ideal" to me.

I prefer an option where I can write and deploy code, and never touch it, or 
even the server/tools, again (if I don't need to), and it will just continue to 
work "forever". For awhile, tests will end up serving both files, but 
eventually, as browsers evolve, the tests will all result in only the *.es6.js 
files being served. To me, that's "ideal".

In short, I don't actually want to think *at all* about what browsers do what 
things. To whatever extent possible, I want feature tests to handle that 
entirely. I think browser versions are meaningless arbitrary marketing labels. 
caniuse data is, at best, amusement to me. I never make real decisions based on 
it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[James Kyle]

Re: shallow testing


Yes you've said that, but this is exactly what `@supports` is in CSS. There was 
no way to do shallow testing so they added a way to do it.




Re: Bootstrapping




This is exactly my point, you're already using multiple builds and letting a 
transpiler handle it for you. Why would you opt for a worse solution than 
letting transpilers handle even more than you?




Here's my ideal situation:




For users who want targeted builds:

1. The transpiler handles building multiple files for various targeted 
environments.

  - Using a known set of feature support (similar to caniuse).

2. Server uses header information to send down the appropriate built file

  - Using the same known set of feature support.




For users who want a single build:

1. The transpiler builds a single file which supports every targeted environment

2. Server sends the same file for everyone.




Neither of these are perfect solutions, but they are a lot better than needing 
to make multiple requests just to determine what version of the site to serve.

On Wed, Mar 25, 2015 at 2:17 PM, Kyle Simpson  wrote:

>> It's not that it's imperfect. It's that it's useless in the real world.
> It's clear it's useless to you. It's not clear that it's useless to everyone. 
> In fact, I for one definitely find it useful. No sense in continuing to argue 
> over subjective opinion.
>> We can already do shallow testing of APIs. Reflect.support doesn't help 
>> there, and in some ways (that I've outlined before) it is a regression.
>> 
>> ```
>> if (!Array.prototype.includes) { ... }
>> if (!Reflect.supports("Array.prototype.includes")) { ... }
>> ```
> As I've repeatedly said, this proposed feature is not for those sorts of 
> tests. It's for all the syntax tests that require `try..catch` + `Function` / 
> `eval`. Please (re)read the rest of the thread.
>> You also wouldn't do testing of syntax support at runtime
> I already do. I fully intend to keep doing so.
>> as you would effectively be duplicating the code.
> Nope, not duplicating code. Maintaining code in original ES6+ authored form 
> as well as transpiled form. They're both files that can be loaded by a 
> browser. So my intent is to decide at runtime which one is appropriate, and 
> only load one or the other.
>> ...send down a file that tests for support and then sends it back to the 
>> server
> Yep, absolutely. Bootstrapping.
>> and then build the appropriate assets for that browser?
> Of course not. It picks one of two already existing files.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Kos Ddsky]

>
>  It's not that it's imperfect. It's that it's useless in the real world.

...

> What's the alternative? To send down a file that tests for support and
> then sends it back to the server and then build the appropriate assets for
> that browser?


Its possible in the AMD approach. Idk though if its useful.

The need in TCO detection is really debatable, but one might be using it,
say, in two years from now to throw a _proper_ exception while running some
crazy recursive code in an old browser.

NB: it would be practical only if feature detection possibility lands to a
browser with (or even before) corresponding feature. And, imho, that's what
Kyle Simpson meant, starting the thread: handy feature detection available
_prior_ to feature implementation.

Two more off-topic cents:
If at any point we will

   - have adjustable features, like disabling at some scope `eval`, `with`,
   `Function()` or using `global object`
   - or a new `stricter mode`
   - or choosing new Number representation
   - ... or whatever

it would be nice to be able to detect such state, without `try..catch` in a
fast & semantic way.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Kyle Simpson]

> It's not that it's imperfect. It's that it's useless in the real world.

It's clear it's useless to you. It's not clear that it's useless to everyone. 
In fact, I for one definitely find it useful. No sense in continuing to argue 
over subjective opinion.


> We can already do shallow testing of APIs. Reflect.support doesn't help 
> there, and in some ways (that I've outlined before) it is a regression.
> 
> ```
> if (!Array.prototype.includes) { ... }
> if (!Reflect.supports("Array.prototype.includes")) { ... }
> ```

As I've repeatedly said, this proposed feature is not for those sorts of tests. 
It's for all the syntax tests that require `try..catch` + `Function` / `eval`. 
Please (re)read the rest of the thread.


> You also wouldn't do testing of syntax support at runtime

I already do. I fully intend to keep doing so.


> as you would effectively be duplicating the code.

Nope, not duplicating code. Maintaining code in original ES6+ authored form as 
well as transpiled form. They're both files that can be loaded by a browser. So 
my intent is to decide at runtime which one is appropriate, and only load one 
or the other.


> ...send down a file that tests for support and then sends it back to the 
> server

Yep, absolutely. Bootstrapping.


> and then build the appropriate assets for that browser?

Of course not. It picks one of two already existing files.

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

Re: Supporting feature tests directly

[James Kyle]

It's not that it's imperfect. It's that it's useless in the real world.




We can already do shallow testing of APIs. Reflect.support doesn't help there, 
and in some ways (that I've outlined before) it is a regression.




```

if (!Array.prototype.includes) { ... }

if (!Reflect.supports("Array.prototype.includes")) { ... }

```




You also wouldn't do testing of syntax support at runtime, as you would 
effectively be duplicating the code.




```

var myFunc;

if (Reflect.supports("TCO")) {

  myFunc = recursiveImplementation;

} else {

  myFunc = nonRecursiveImplementation;

  // Why duplicate? You'd be saving yourself a lot of hassle by just 
transpiling to this

}

```




What's the alternative? To send down a file that tests for support and then 
sends it back to the server and then build the appropriate assets for that 
browser?




No, that'd be absurdly slow, and now you've already delegated to using a build 
tool.




- James Kyle

On Wed, Mar 25, 2015 at 1:44 PM, Kyle Simpson  wrote:

> What this sub-discussion of CSS `supports(..)` is reinforcing is what I said 
> earlier: a capability to do feature tests in a direct, efficient, and 
> non-hacky manner is valuable to some/many uses and use-cases, even with the 
> recognition that it doesn't have to *perfectly* support all conceivable 
> uses/use-cases/tests.
> We should avoid a mindset that anything short of perfect isn't worth doing at 
> all. Thankfully JS doesn't have such a design principle.
> A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally 
> or intentionally lie. But it *could* be better to some audiences than having 
> no information. I personally would prefer to use it, even with its "risks", 
> than trying a long recursive loop in a `try..catch` to imply if TCO was in 
> effect.
> Nevertheless, it's the least important kind of test being advocated for here, 
> even though it seems to be getting all the attention. If that kind of test is 
> a bone of contention, it should be the easiest to drop/ignore.
> Moreover, to reduce the risk of bitrot on feature lookup tables (that 
> `Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems 
> like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )` 
> type of test.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Kyle Simpson]

What this sub-discussion of CSS `supports(..)` is reinforcing is what I said 
earlier: a capability to do feature tests in a direct, efficient, and non-hacky 
manner is valuable to some/many uses and use-cases, even with the recognition 
that it doesn't have to *perfectly* support all conceivable 
uses/use-cases/tests.

We should avoid a mindset that anything short of perfect isn't worth doing at 
all. Thankfully JS doesn't have such a design principle.

A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally or 
intentionally lie. But it *could* be better to some audiences than having no 
information. I personally would prefer to use it, even with its "risks", than 
trying a long recursive loop in a `try..catch` to imply if TCO was in effect.

Nevertheless, it's the least important kind of test being advocated for here, 
even though it seems to be getting all the attention. If that kind of test is a 
bone of contention, it should be the easiest to drop/ignore.

Moreover, to reduce the risk of bitrot on feature lookup tables (that 
`Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems 
like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )` 
type of test.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Tab Atkins Jr.]

On Wed, Mar 25, 2015 at 1:17 PM, James Kyle  wrote:
> The reason `@supports` works in CSS is because of the limited language
> feature-set CSS has, but this wouldn't work in JavaScript.

No, it works because most of the time, whether or not something parses
is a sufficient proxy for "this is supported".  This isn't always
adequate - for example, you can't test whether a browser supports APNG
in CSS properties with this - but that's okay.

Similarly, a JS version would let you test for anything where parsing
is a proxy for support, like "function*(){...}" or "()=>{}".  It
wouldn't help you with things where parsing is successful whether the
feature is supported or not.

There's no good way to support those cases that parsing doesn't
address besides direct feature tests, or support tables.  Luckily,
both of these already exist in the ecosystem, so it's okay that we're
not solving them.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[James Kyle]

The reason `@supports` works in CSS is because of the limited language 
feature-set CSS has, but this wouldn't work in JavaScript.




To reuse the TCO example:




```

var supportsTCO = Reflect.supports('function recursive() { recursive() }');

```




Of course that will parse, and executing it wouldn't be a good idea.




Transpilers can solve this problem. I've been working on Babel to get 
caniuse-like browser support data to be smarter about handling what to 
transpile.




- "I want to support the last two versions of every browser, transpile/polyfill 
that for me."

- "I want to support these features, what browser support will I have?"

On Wed, Mar 25, 2015 at 12:32 PM, Tab Atkins Jr. 
wrote:

> On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
>  wrote:
>> For consistency sake I agree, but I come from a world where browsers also
>> exposed unofficially APIs so that, as James mentioned already,
>> `Array.prototype.includes` would have returned true and never worked.
>>
>> I wonder how reliable is `CSS.supports` not just in term of syntax, but
>> actual usability.
> You give it a full property declaration, and if the browser can parse
> it successfully, it returns true/false.  This allows for false
> positives (a browser parsing a property but not actually supporting it
> yet), but devs (rightfully) yell and scream at browsers whenever that
> case (parse but no support) happens, so we do it very rarely, and only
> ever by accident.
> It's just a standardized version of the de facto standard CSS feature
> test of "set the property on an element, and try to read it back; if
> you get something, it's supported".
> Because it's based on an objective and reliable criteria tied to
> directly to actual support (successful parsing), it's reliable in
> practice as a feature test.  This differentiates it from the old
> hasFeature() function, which was based on a map of feature strings to
> bools stored in the browser, with no connection to the actual features
> in question, and so was inevitably filled with lies and bitrot.
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Expression Closures as Compliment to Arrow Functions

[Isiah Meadows]

Would this be rectifiable with something like an unbound lambda type
syntax? You could even make an analogous equivalent for classes.

```js
// Lambda, unbound, ASI applies, same precedence as current arrow functions
() -> foo;
(x) -> bar(1, x);
x -> bar(1, x); // same as previous
(...args) -> foo(this, ...args);
() -> {
  try {
foo();
return true;
  } catch (e) {
return false;
  }
};

// Useful for jQuery, etc.
$('.foo').each(() -> $(this).hide());

// For classes
class Foo {
  // shorthand method, only allowed
  // in ClassBody to limit ambiguity
  bar () -> this.foo.toLowerCase();
  get chars () -> this.bar().split("");
  constructor(foo="") {
this.foo = foo;
  }
}

// Prototypal
const Foo = {
  bar: () -> this.foo.toLowerCase(),
  get chars () -> this.bar().split(""),
  init: (foo="") -> this.foo = foo,
};

// let foo1 = Object.create(Foo);
// foo1.init();

let foo1 = new Foo();

// let foo2 = Object.create(Foo);
// foo2.init("Foo!");
let foo2 = new Foo("Foo!");

foo1.bar(); // ""
foo2.bar(); // "foo!"
foo1.chars; // []
foo2.chars; // ["f", "o", "o", "!"]
```

I think an unbound lambda like that above would be the best, most flexible
solution. Obviously, some inspiration is taken from CoffeeScript, but it
works.

Also, the syntax would be identical to that of arrow functions, except
substitute the arrow type, "=>" to "->".

Now, as for potential syntax ambiguities, there shouldn't exist any.

- "n-->1" vs "n->1": The character after the first hyphen will decide how
it's parsed. If it's ">", then it represents an unbound arrow function.
- "foo () {}" vs "foo () -> this.bar": If the first character after the
arguments list is an opening curly brace, then it is a concise method. If
it's a hyphen, it's an unbound arrow lambda definition. Same logic for
getters/setters.
- "static foo () {}" vs "static foo () -> bar" vs "static foo () => bar":
see above

These unbound lambdas would be terminated just like arrow functions, and in
classes, the ASI is after the expression statement or block statement.

Basically, the grammar would be otherwise identical to arrow functions,
except for both types can substitute for static method arguments + body and
unbound for instance method arguments + body.

Any interest in this solution? Also, WDYT?

```js
class Foo {
  // This syntax is only allowed in
  // a ClassBody
  foo () -> this;
  foo2 x -> f(this, x);
  foo3 (x, y) -> f(this, x, y);
  get bar () -> this._bar;
  set bar val -> this._bar = 2;
  static baz () => blarg();
  static get quux () => foo();
  static set quux val => foo(val);
}
$(".foo").each(() -> $(this).hide());
list.forEach(x => x * 2);
let f = x => x + 1;
let g = () -> h(this);
```

> From: Brendan Eich 
> To: Jacob Parker 
> Cc: es-discuss@mozilla.org
> Date: Wed, 25 Mar 2015 14:30:28 +0100
> Subject: Re: Expression Closures as Compliment to Arrow Functions
> Jacob Parker wrote:
>>
>>
>> Could the comma not be the delimiter, as I think works with arrow
functions, or is that more precedence issues?
>>
>
> No precedence issue, due to AssignmentExpression (not Expression) being
the right-most non-terminal produced by the unbraced alternative for
ConciseBody.
>
> In a class body, comma is the wrong separator (delimiter? trailing comma
allowed in most JS contexts, but still) -- see the live ES7 proposal from
Jeff Morrison, inspired by TypeScript and Flow:
>
> https://gist.github.com/jeffmo/054df782c05639da2adb
>
> Class bodies are not object initialisers, in notable ways, even though
concise methods have the same syntax and (parameterizing `super`
differently according to context) semantics.
>
> Class bodies are not block statements, either, of course. But this
doesn't rule out ; or favor , instead. It just means no ASI insanity. ;-)
>
> /be
>>
>>
>> On Wed, 25 Mar 2015 8:37 am Brendan Eich > wrote:
>>
>> Jacob Parker wrote:
>> > In the context of only objects and classes, is this format no-go?
>>
>> Without the } that closes a concise method body, there's a new
problem
>> to-do with computed property names:
>>
>> class C {
>>m() this._m
>>[Symbol.iterator]() {/*...*/}
>> }
>>
>> We need a delimiter. Could use ; without ASI, so it'd look like this:
>>
>> class C {
>>m() this._m;
>>[Symbol.iterator]() {/*...*/}
>> }
>>
>> I haven't checked for other problems, but wanted to throw this out
and
>> see if anyone else sees a live one.
>>
>> /be
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Tab Atkins Jr.]

On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
 wrote:
> For consistency sake I agree, but I come from a world where browsers also
> exposed unofficially APIs so that, as James mentioned already,
> `Array.prototype.includes` would have returned true and never worked.
>
> I wonder how reliable is `CSS.supports` not just in term of syntax, but
> actual usability.

You give it a full property declaration, and if the browser can parse
it successfully, it returns true/false.  This allows for false
positives (a browser parsing a property but not actually supporting it
yet), but devs (rightfully) yell and scream at browsers whenever that
case (parse but no support) happens, so we do it very rarely, and only
ever by accident.

It's just a standardized version of the de facto standard CSS feature
test of "set the property on an element, and try to read it back; if
you get something, it's supported".

Because it's based on an objective and reliable criteria tied to
directly to actual support (successful parsing), it's reliable in
practice as a feature test.  This differentiates it from the old
hasFeature() function, which was based on a map of feature strings to
bools stored in the browser, with no connection to the actual features
in question, and so was inevitably filled with lies and bitrot.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Always close iterators?

[Bergi]

Axel Rauschmayer wrote:

Given that redundant calls to `return()` don’t make a difference (h/t Bergi)


I'm sorry, that was not 100% accurate. I only referred to `.return(x)` 
returning {done:true, value:x} and `.throw(e)` being equivalent to 
`throw e;` when the generator was never started or is already completed 
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorresumeabrupt).
In fact, there are generators that behave differently when being 
prematurely aborted and attempted to be closed multiple times.

A contrived example:

  function* unstoppableCounter(n) {
   try {
   while (true)
   yield n++;
   } finally {
   console.log("unclosable!");
   yield* unstoppableCounter(n);
   }
   }

   var counter = unstoppableCounter(0);
   var i=5;
   for (var x of counter) {
   console.log(x);
   if (!--i) break;
   }
   i=4;
   for (var x of counter) {
   console.log(x);
   if (!--i) break;
   }

Every call of `counter.return()` here would actually log "unclosable!", 
increase the counter and yield {done:false, value:…} - in general, might 
have side effects. So we shouldn't do it arbitrarily often.


> couldn’t the iteration protocol be simpler if iterators were always 
closed. “Manually implemented” iterators could be written without the 
check in line (A)


I don't think that's how an explicit iterator would be written. 
Shouldn't it look more like


  …
  next() {
  if (iterationIsDone()) {
  cleanUp();
  return {done: true};
  } else {
  return {value: nextValue(), done: false};
  }
  }

Of course that assumes that we don't have a return value, and `next()` 
is no more called after it returned `done: true` once (otherwise we'd 
clean up multiple times).

Maybe better:

  …
  next() {
  if (iterationIsDone()) {
  return {done: true};
  } else {
  let result = {value: nextValue(), done: iterationIsDone()};
  if (result.done) cleanUp(); // (B)
  return result;
  }
  }

Admittedly, that has the line you argued against again…

 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Andrea Giammarchi]

For consistency sake I agree, but I come from a world where browsers also
exposed unofficially APIs so that, as James mentioned already, `
Array.prototype.includes` would have returned true and never worked.

I wonder how reliable is `CSS.supports` not just in term of syntax, but
actual usability.

Best Regards

On Wed, Mar 25, 2015 at 7:44 PM, Tab Atkins Jr. 
wrote:

> On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
>  wrote:
> > +1 to Kyle proposal, using eval or Function is not even an option in CSP
> > constrained environments ( unless the relative code is provided as
> SHA256,
> > then we need to agree on how such code should look like and share it as
> > polyfill )
> >
> > I'd also suggest `Reflect.isValidSyntax` as alternative to
> > `Reflect.supports` 'cause it's less misleading when it comes to figure
> out
> > APIs support and their implementation.
> >
> > After all, that's exactly what we'd like to know, if a generic syntax
> will
> > break or not.
>
> CSS has an exactly analogous feature already, and calls it
> CSS.supports().  That's a decent reason to stick with supports() as
> the name.
>
> ~TJ
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Tab Atkins Jr.]

On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
 wrote:
> +1 to Kyle proposal, using eval or Function is not even an option in CSP
> constrained environments ( unless the relative code is provided as SHA256,
> then we need to agree on how such code should look like and share it as
> polyfill )
>
> I'd also suggest `Reflect.isValidSyntax` as alternative to
> `Reflect.supports` 'cause it's less misleading when it comes to figure out
> APIs support and their implementation.
>
> After all, that's exactly what we'd like to know, if a generic syntax will
> break or not.

CSS has an exactly analogous feature already, and calls it
CSS.supports().  That's a decent reason to stick with supports() as
the name.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Iterating default function arguments

[Robin Cafolla]

Well my use case is for something I can insert into an existing function,
in fact, a lot of functions, hopefully without manually listing the
arguments.

```js
function bar( parameters ) {
for ( var i = 0; i < parameters.length; i++ ) {
// do something interesting with each parameter of the function
}
}

function foo( a, b = 2 ) {
bar( parameters );

// do normal foo stuff
}
```

Thinking about it I can't see how Reflect could do this, because it's
surely meant to be external to the function. For example with an imaginary
Reflect.getParameters:

```js
Reflect.getParameters( foo ) // could only give me [ a: undefined, b: 2 ]
as reflect can't know what foo was called with from outside the function.
```

On 25 March 2015 at 19:12, Axel Rauschmayer  wrote:

> I'm all for using Reflect, but looking at the API as listed on MDN, the
>>> harmony-reflect github, or the spec, i don't see an obvious way of getting
>>> the parameters.
>>>
>>
>
> If I understand you correctly (and this is not about parsing the parameter
> definitions) then how about the following solution?
>
> ```js
> function foo(…args) {
> let [a, b = 2] = args;
> return args;
> }
> ```
>
> Original code:
>
> ```js
> function foo( a, b = 2 ) {
> return arguments;
> }
> ```
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Iterating default function arguments

[Axel Rauschmayer]

> I'm all for using Reflect, but looking at the API as listed on MDN, the 
> harmony-reflect github, or the spec, i don't see an obvious way of getting 
> the parameters.


If I understand you correctly (and this is not about parsing the parameter 
definitions) then how about the following solution?

```js
function foo(…args) {
let [a, b = 2] = args;
return args;
}
```

Original code:

```js
function foo( a, b = 2 ) {
return arguments;
}
```

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de

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

Re: Iterating default function arguments

[Robin Cafolla]

Oops. Sorry about that.

On 25 March 2015 at 19:01, Andrea Giammarchi 
wrote:

> you keep replying to me only ... you really need to reply-all since I've
> actually no idea ;-)
>
> On Wed, Mar 25, 2015 at 5:53 PM, Robin Cafolla 
> wrote:
>
>> I'm all for using Reflect, but looking at the API as listed on MDN, the
>> harmony-reflect github, or the spec, i don't see an obvious way of getting
>> the parameters.
>>
>> https://github.com/tvcutsem/harmony-reflect/blob/master/doc/api.md
>>
>> What am I missing?
>>
>> On 25 March 2015 at 18:39, Andrea Giammarchi > > wrote:
>>
>>> Sounds good to me and makes perfect sense. Robin?
>>>
>>> On Wed, Mar 25, 2015 at 5:23 PM, Brendan Eich 
>>> wrote:
>>>
 Andrea Giammarchi wrote:

> I think the answer is still a static `[a, b]` as list of arguments to
> apply, but I can see some lack of "reflection" capability ... or maybe
> Reflect would solve this?
>

 Yes, Reflect -- we want a mirror approach, not more magic object like
 arguments or function.

 /be

>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Forwarding `return()` in generators

[Axel Rauschmayer]

>> But: you need to guard against other ways of reaching `finally`.
> 
> Why? I intended to always reach finally, and always close the iterator. Also, 
> simplicity ftw :-)
> 
> > That’s not what all the other constructs in ES6 do: they only call 
> > `return()` if iteration stops abruptly.
> 
> Only because all the other constructs in ES6 try to exhaust the iterator. And 
> when it's finished anyway, one doesn't need to close it.
> There is in fact no problem with calling `.return()` too often, it just 
> doesn't do anything to completed generators.

True. I hadn’t thought of that.

> Btw, your `take` function is the perfect example where a non-exhausted 
> iterator *should* be closed as return prematurely - like a `break` in a 
> for-of loop would.

Right. Always closing is much simpler. Otherwise, you’d have to check whether 
everything was exhausted or not.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Iterating default function arguments

[Andrea Giammarchi]

Sounds good to me and makes perfect sense. Robin?

On Wed, Mar 25, 2015 at 5:23 PM, Brendan Eich  wrote:

> Andrea Giammarchi wrote:
>
>> I think the answer is still a static `[a, b]` as list of arguments to
>> apply, but I can see some lack of "reflection" capability ... or maybe
>> Reflect would solve this?
>>
>
> Yes, Reflect -- we want a mirror approach, not more magic object like
> arguments or function.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Always close iterators?

[Axel Rauschmayer]

Given that redundant calls to `return()` don’t make a difference (h/t Bergi), 
wouldn’t the iteration protocol be simpler if iterators were always closed 
(versus only if iteration finishes abruptly). The code of generators wouldn’t 
change (`finally` etc.), but “manually implemented” iterators could be written 
without the check in line (A). They’d become simpler and more similar to 
generators and `finally`.

```js
let iterable = {
[Symbol.iterator]() {
return {
next() {
if (iterationIsDone()) {
return { done: true };
} else {
let result = { value: nextValue(), done: false };
if (iterationIsDone()) { // (A)
 cleanUp();
}
return result;
}
},
return(value) {
if (! iterationIsDone()) {
cleanUp();
}
return { value: value, done: true };
}
}
}
}
```

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Forwarding `return()` in generators

[Axel Rauschmayer]

Good point, if it is about iteration, only `return()` needs to be propagated.

> On 24 Mar 2015, at 23:35, Ron Buckton  wrote:
> 
> Is your goal to wrap a generator, as it seems you are propagating the 
> exception of the caller by calling iterator.throw(). However, you do not seem 
> to be propagating the sent value, so the protocol here isn’t fully 
> implmeneted.
>  
> If you just want to iterate values (and don’t really care about the return 
> value of the iterable or propagating a thrown exception, you could write:
>  
> ```js
> function* take(n, iterable) {
>   n |= 0;
>   if (n <= 0) {
> return;
>   }
>   // let for..of call return()
>   for (let value of iterable) {
> yield value;
> if (n-- <= 0) {
>   return;
> }
>   }
> }
> ```
>  
> If you want to support the full communication channel of a generator, you 
> could write:
>  
> ```js
> function* take(n, iterable) {
>   let iterator = iterable[Symbol.iterator]();
>   let step = () => iterator.next();
>   n |= 0;
>   // try..finally outside of loop
>   try {
> let sent;
> while (n > 0) {
>   let { value, done } = step();
>   if (done) {
> return value;
>   }
>   n--;
>   // try..catch local to the yield
>   try {
> sent = yield value;
> step = () => iterator.next(sent);
>   }
>   catch (e) {
> if (typeof iterator.throw === "function") {
>   step = () => iterator.throw(e);
> }
> else {
>   throw e;
> }
>   }
> }
>   }
>   finally {
> if (typeof iterator.return === "function") {
>   iterator.return();
> }
>   }
> }
> ```
>  
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org 
> ] On Behalf Of Axel Rauschmayer
> Sent: Tuesday, March 24, 2015 2:28 PM
> To: Bergi
> Cc: es-discuss list
> Subject: Re: Forwarding `return()` in generators
>  
> Right, it doesn’t look like one needs to know the returned value when 
> forwarding `return()`.
>  
> But: you need to guard against other ways of reaching `finally`. Maybe like 
> this:
>  
> ```js
> function* take(n, iterable) {
> let iterator = iterable[Symbol.iterator]();
> n = +n; // make sure it's a number, so that n>0 does never throw
> let forwardReturn = true;
> try {
> while (n > 0) {
> let item = iterator.next();
> if (item.done) {
> forwardReturn = false;
> return item.value;
> }
> yield item.value;
> n--;
> }
> forwardReturn = false;
> } catch (e) {
> forwardReturn = false;
> iterator.throw(e);
> } finally {
> if (forwardReturn) {
> iterator.return();
> }
> }
> }
> ```
> The above code also has the additional nice property that it call `.return()` 
> on the iterator when `n` values have been taken out of it.
>  
> That’s not what all the other constructs in ES6 do: they only call `return()` 
> if iteration stops abruptly.
>  
> Also missing from this code: checking whether the iterator actually has the 
> methods `return()` and `throw()` and responding accordingly.


-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



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

Re: Iterating default function arguments

[Brendan Eich]

Andrea Giammarchi wrote:
I think the answer is still a static `[a, b]` as list of arguments to 
apply, but I can see some lack of "reflection" capability ... or maybe 
Reflect would solve this?


Yes, Reflect -- we want a mirror approach, not more magic object like 
arguments or function.


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

Re: `import` and hoisting

[caridy]

yes, they will work. "hoisting of function initialization happens across the 
whole module linkage graph before any module initialization code starts 
executing." quoting @dherman.

there is one thing to keep in mind though: many edge cases cannot be transpile 
into CJS, AMD, etc., the only format that preserves all the semantics of the 
module system is the `system` format, which is an experimental format we came 
up with a while ago. those two examples might fail in babeljs, but they 
definitely work on esnext module transpiler (which is already deprecated), but 
at least will give you an idea of how things work internally: 
http://bit.ly/1ETGVDA

/caridy

> On Mar 20, 2015, at 2:20 PM, Axel Rauschmayer  wrote:
> 
> As far as I can tell, `import` is hoisted (due to 
> `ModuleDeclarationInstantiation`). Is the following code OK, then? No 
> temporal dead zone?
> 
> ```js
> bar();
> 
> import {foo} from 'mymodule';
> 
> function bar() { // hoisted!
> foo(); // already initialized?
> }
> ```
> 
> How about this code?
> 
> ```js
> foo();
> 
> import {foo} from 'mymodule';
> ```
> 
> Thanks!
> 
> Axel
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
> 
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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

Re: Iterating default function arguments

[Andrea Giammarchi]

I think the main concern was:

> Currently I can't see a way of getting default parameters as an iterable
object.

 and indeed `arguments` is not the magic variable you are looking for.

However, you are inside your own defined function so either you don't
specify defaults, or you iterate over `[a, b]` ?

Interesting enough, there's no actually a way to understand the function
signature, in terms of optionally accepted arguments.

`arguments.length` is one and same is for `foo.length` so if we'd like to
understand if anyone invoked the function passing or not all optional
parameters, how could we proceed?

Lets say `foo` would like to delegate its own arguments including defined
defaults to another function ... how can we grab these at runtime?

I think the answer is still a static `[a, b]` as list of arguments to
apply, but I can see some lack of "reflection" capability ... or maybe
Reflect would solve this?

Regards




On Wed, Mar 25, 2015 at 4:56 PM, Rick Waldron 
wrote:

>
>
> On Wed, Mar 25, 2015 at 2:40 AM Robin Cafolla 
> wrote:
>
>> Hi there,
>>
>> I was wondering if there were any plans to modify `arguments` to include
>> default parameters (e.g. changing it from a simpleParameterList) or to
>> include a new property that does allow iteration of all values available to
>> a function.
>>
>> for example:
>>
>> function foo( a, b = 2 ) {
>> return arguments;
>> }
>>
>> console.log( foo( 1 ) ); // outputs [ 1 ], not [ 1, 2 ]
>>
>> Currently I can't see a way of getting default parameters as an iterable
>> object.
>>
>> I filed a bug with Mozilla over this, but they pointed out that the
>> behaviour matches the spec.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1144672
>>
>
>
> This is correct, because only one _argument_ was passed, therefore the
> arguments object has only one entry. Parameters are not the same as
> Arguments.
>
> Therefore:
>
>   foo(1, 3) => [1, 3]
>
> Because two arguments were passed. And:
>
>   foo(1, 2, 3) => [1, 2, 3]
>
> Because three were passed.
>
> Hopefully that helps clarify?
>
> Rick
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Iterating default function arguments

[Rick Waldron]

On Wed, Mar 25, 2015 at 2:40 AM Robin Cafolla 
wrote:

> Hi there,
>
> I was wondering if there were any plans to modify `arguments` to include
> default parameters (e.g. changing it from a simpleParameterList) or to
> include a new property that does allow iteration of all values available to
> a function.
>
> for example:
>
> function foo( a, b = 2 ) {
> return arguments;
> }
>
> console.log( foo( 1 ) ); // outputs [ 1 ], not [ 1, 2 ]
>
> Currently I can't see a way of getting default parameters as an iterable
> object.
>
> I filed a bug with Mozilla over this, but they pointed out that the
> behaviour matches the spec.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1144672
>


This is correct, because only one _argument_ was passed, therefore the
arguments object has only one entry. Parameters are not the same as
Arguments.

Therefore:

  foo(1, 3) => [1, 3]

Because two arguments were passed. And:

  foo(1, 2, 3) => [1, 2, 3]

Because three were passed.

Hopefully that helps clarify?

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `import` and hoisting

[Kyle Simpson]

bump.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Supporting feature tests directly

[Brendan Eich]

Kyle Simpson wrote:

Totally disagree here. Anyone that's following the (Crockford) advice of not 
using loops anymore and writing all recursion absolutely cares if such code can 
be directly loaded into a browser or not.


LOL.

I don't think Crock was totally serious there... Let's get PTC support 
in all engines and then find out.


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

Re: Extending object literal property value shorthand

[Rick Waldron]

Inline...

On Wed, Mar 25, 2015 at 12:25 AM Bob Myers  wrote:

> Thanks Rick. Yes, I had been hoping to make the following work:
>
> x = {a: 1};
> y = {b: 2};
> z = {x.a, b.y}; // {a: 1, b: 2}
>
> This is not destructuring per se.
>

Of course, and that's not what I was exploring in attempting to extend
12.2.5.9 Runtime Semantics: PropertyDefinitionEvaluation


> It's an extension to object literal property value shorthand syntax.
> The idea was to derive the desired property name `a` from `x.a`.
> This seems compact and readable.
>


> However, as you found it could be difficult to define when and how a
> property name could be derived from various types of member expressions.
>

After more thought, I think it can be done with a set of explicit early
errors that disallow a subset of MemberExpression nonterminals.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Expression Closures as Compliment to Arrow Functions

[Brendan Eich]

Jacob Parker wrote:


Could the comma not be the delimiter, as I think works with arrow 
functions, or is that more precedence issues?




No precedence issue, due to AssignmentExpression (not Expression) being 
the right-most non-terminal produced by the unbraced alternative for 
ConciseBody.


In a class body, comma is the wrong separator (delimiter? trailing comma 
allowed in most JS contexts, but still) -- see the live ES7 proposal 
from Jeff Morrison, inspired by TypeScript and Flow:


https://gist.github.com/jeffmo/054df782c05639da2adb

Class bodies are not object initialisers, in notable ways, even though 
concise methods have the same syntax and (parameterizing `super` 
differently according to context) semantics.


Class bodies are not block statements, either, of course. But this 
doesn't rule out ; or favor , instead. It just means no ASI insanity. ;-)


/be


On Wed, 25 Mar 2015 8:37 am Brendan Eich > wrote:


Jacob Parker wrote:
> In the context of only objects and classes, is this format no-go?

Without the } that closes a concise method body, there's a new problem
to-do with computed property names:

class C {
   m() this._m
   [Symbol.iterator]() {/*...*/}
}

We need a delimiter. Could use ; without ASI, so it'd look like this:

class C {
   m() this._m;
   [Symbol.iterator]() {/*...*/}
}

I haven't checked for other problems, but wanted to throw this out and
see if anyone else sees a live one.

/be


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

Re: Expression Closures as Compliment to Arrow Functions

[Jacob Parker]

Could the comma not be the delimiter, as I think works with arrow
functions, or is that more precedence issues?

On Wed, 25 Mar 2015 8:37 am Brendan Eich  wrote:

> Jacob Parker wrote:
> > In the context of only objects and classes, is this format no-go?
>
> Without the } that closes a concise method body, there's a new problem
> to-do with computed property names:
>
> class C {
>m() this._m
>[Symbol.iterator]() {/*...*/}
> }
>
> We need a delimiter. Could use ; without ASI, so it'd look like this:
>
> class C {
>m() this._m;
>[Symbol.iterator]() {/*...*/}
> }
>
> I haven't checked for other problems, but wanted to throw this out and
> see if anyone else sees a live one.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Expression Closures as Compliment to Arrow Functions

[Brendan Eich]

Jacob Parker wrote:

In the context of only objects and classes, is this format no-go?


Without the } that closes a concise method body, there's a new problem 
to-do with computed property names:


class C {
  m() this._m
  [Symbol.iterator]() {/*...*/}
}

We need a delimiter. Could use ; without ASI, so it'd look like this:

class C {
  m() this._m;
  [Symbol.iterator]() {/*...*/}
}

I haven't checked for other problems, but wanted to throw this out and 
see if anyone else sees a live one.


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