Once you focus on inline bodies, you face harsh adoption barriers without
enabling works-in-old-and-new coding.
OK, I follow.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
7) Hence, it probably makes sense to promote a convention of using a new
file extension for ES6 source files that are intended to be parsed with the
modules goal. .jsm, or mjs, or something similar that is appropriately
suggestive and isn't already widely used as an extension.
Allen, I'm
I'm perfectly happy with convention of some kind:
a) a file extension
b) a comment on the first line of the file:
// module mymodule
c) a use strict style annotation that is just documentation:
module mymodule;
One of the nicest things about the current modules syntax is that it avoids
Couple of nits WRT modules:
- The instantiationRequest interface is defined as having two properties:
execute and deps. I believe deps should be spelled dependencies
to match the naming conventions throughout the rest of the document.
Besides that, there is no reason that I can see to optimize
First, there are plenty of standard bindings on the global object that
are not constructors and yet are capitalized -- `Math` is a prime
example here.
Math (and Reflect, JSON, etc) are functioning not as objects with
per-instance state, but as namespaces. Infinity is a value object, but
I'm inclined to say this has missed the train for ES6.
That may be fine. It seems like we would use a little more experience
with ES6 modules before we tackle this.
Definitely. It appears that the only thing in the ES6 draft which mentions
standard modules is GeneratorFunction. Will that
What's the method for determining whether we run the multimethod dispatch
algorithm versus the ES6 abstract equality algorithm?
One or both operands value objects.
Gotcha. One more, I think.
int64(0) === 0L
I assume that int64 is not defined as a composition of primitives or value
[oops - reply all this time]
Value objects have value, not reference, semantics. JS has string number
boolean already (note lowercase names). With value objects, users and the
host env can define others.
Makes sense, but I thought the user could not define semantics for ===:
it just means
js 0L == 0
typein:2:0 TypeError: no operator function found for ==
And what does this do?
0L == { valueOf() { return 0 } }
Is the Object-type operand converted to a primitive before the overload is
matched?
___
es-discuss mailing list
js 0L == { valueOf: function() { return 0 } }
typein:2:0 TypeError: no operator function found for ==
Is the Object-type operand converted to a primitive before the overload
is matched?
No, the multimethod dispatch algorithm runs. Even with ToObject (I see I
left that out), there is
In the worst case, when I don't know if I have a string or an URLUtils
object, I just ensure that at least one member of the equality operator is
stringified—and, most importantly, that it is evident from reading my code
that one member is stringified:
a.href == url
In JS world we are use to compare via === so that when == is used
instead we are usually in power user land, I don't see any conceptual
shenanigans in doing something like above code.
Only power users use == because it has weird conversion semantics that
are hard to internalize. == doesn't
== is overloadable along with and = to cope with unordered values and
to enable common safe comparisons, e.g. 0m == 0.
What does 0m === 0 mean?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`0m` is literal syntax, for `decimal(0)`. Where `decimal` is a value type
factory.
Right - I meant what are the semantics of === applied to dissimilar,
perhaps numeric, value types.
___
es-discuss mailing list
es-discuss@mozilla.org
While opinions vary, the fact remains that == and = are in the language,
are loose, and need to be overloadable for useful value objects,
specifically more numeric types.
I agree, that must be a goal of the design.
Suggest you pull == out of your mental penalty box and look at it again.
So glad you asked, and you will like the answer:
js 0L == 0
typein:2:0 TypeError: no operator function found for ==
...and..I..do : )
http://goo.gl/N5txLJ
- The strict equality operators, === and !==, cannot be overloaded
- They work on frozen-by-definition value objects via a
Your point about it being too late to salvage == (vs. ===) is good, but
perhaps with value objects plus further work to disable implicit
conversions, == will make a come-back -- but that's far down the road.
Work to disable implicit conversions? Can you clarify?
I'm actually quite wary
No, what is required is
(() = {...whatever...})()
Arrow function expressions are an AssignmentExpression.
Right, I misread Mark's code sample.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I may warm up to the extra complexity more easily if somebody could
present at least some compelling use cases. :)
Mark's mention of yield got me thinking about await expressions. Hopefully
I'm using this correctly:
// stat is null or a Stat object
const stat = do { try { await
I do have one usability concern with arrow IIFEs. I hate when I see them
written as ()={...whatever...}() because you don't know that it's an IIFE
until the end. Function expressions have the same issue. We should adapt
Crock's recommended paren style to arrow IIFEs, to whit
Since do-as-IIFE carries with it a subset of the semantics carried by
do--as-block, I think it makes sense to proceed with the subset first,
and expand if do-as-IIFE turns out to be surprising or lacking.
IIUC, the goal here is to allow a sequence of statements to produce a
value, not
If all you want is a non verbose IIFE, use an arrow function. We should
consider do expressions only if they avoid the TCP violations of strict
arrow IIFEs.
One could say that they are verbose:
var x = (_= { /* some statements, with a return statement somewhere */
})();
vs.
var x =
In KeyKOS we used the word name. We had another meaning for the word
key and wanted to avoid confusion.
Name is good.
Symbol.name(Symbol.for(foo)) === foo;
Or some variant thereof.
___
es-discuss mailing list
es-discuss@mozilla.org
Name is good.
Symbol.name(Symbol.for(foo)) === foo;
Or some variant thereof.
I like this, but it interferes with the name property that all function
objects have—the Symbol.name property would no longer have the expected
value Symbol.
Oh yes - doh! : )
Can you leave what you feel is the best solution aside for a moment and
comment on this proposal instead?
Leave aside the best solution - NEVER!!!
: )
2-year old is bugging me, but I'll respond later...
___
es-discuss mailing list
By the way, I noticed that duck typing here is *already* not done with
symbols. So the argument isn't its either going to be symbols or nothing.
Its its either going to be symbols or the method then.
That's right, and (digging a little deeper) there are two problems with
using symbols:
1.
I highly doubt that will be possible -- experience strongly suggests that
every odd feature _will_ be relied on in the wild by that time. If we think
thenable assimilation is a problem then we have to remove it now. I, for
one, would welcome that. We could still provide an _explicit_ thenable
Presumably certain promise libraries would try reset the global Promise to
AssimilatingPromise (or whatever) for full parity with polyfilled
environments, which would be fine.
If you're using modules, you wouldn't need to mess with the global object.
You could just import
Here is code that breaks with that solution: ``` function
createParser(code) { return {then: chainedTransformation = { ...; return
this; } } } waitForFormSubmit() .then(e = $.get(getUrlFromUrlField()))
.then(code = createParser(code, options)) ```
Not necessarily - if you're using new DOM
Hold on there. If they already do assimilation, why would you even
inherit?
So that the system will see jQuery's assimilating promises as real promises.
So you're saying that promise library authors should rearchitect their
entire libraries, and that solution is better than them just
Banning await here is only a solution if you're also not going to ban an
async descriptor on the arrow expression. THAT is the mistake.
Not sure I follow - can you elaborate? What is an async descriptor on the
arrow expression?
___
es-discuss
=, *=, !=
=, =*, =!
=, *, !
Which do you hate least?
Hate is such a strong world... : )
My aesthetic judgement is that ! is not a good choice because grawl is
bad for beginners. And async functions will touch beginners quite heavily
(I predict).
Btw, Kevin, I have read
I think it's fairly self-evident that they are a natural fit for such use
cases, but I find it less self-evident that they are inherently not useful
for others (e.g., generators). I feel like I keep seeing the following
(implied) argument:
1) Arrow functions are good for mappings
2)
1) Non-mapping iteration (e.g., `forEach()`)
2) Lightweight callbacks
Or, mappings to void.
3) Killing off 90% of `var self = this` occurrences.
Here's is the iffy part. While getting rid of explicit this-binding is
definitely a good thing, we want to make sure that goal fits in with
p2 = p1 ! foo(a, b);
would be equivalent to
p2 = Promise.cast(p1).send(foo, a, b);
which, for local promises, is equivalent to the ES6
p2 = Promise.cast(p1).then(r = r.foo(a, b));
Yes, but ! isn't agreed upon. By that time, we might be over our
CoffeeScript-inspiration
```js
const concat = (a, b) =* { yield* a; yield* b; }
```
Thanks. For this particular example, it's no big deal to use longhand:
function* concat(a, b) { yield* a; yield* b; }
But you could throw a couple of `this`s in there and drive the argument
that way. But are we going to see
Well, let's use it in context then. I think this is correct?
```js
const flattened = iterableReduce(iterableOfIterables, (a, b) =* { yield*
a; yield* b; }, []);
```
Makes sense to me.
Still, what's the alternative?
function* concat(a, b) { yield* a; yield* b; }
const flattened =
I think we should at least consider for a moment reserving `await` within
the body of arrow functions. Consider the following event handling
scenario, where lexical `this` is an important feature:
this.button.on(click, $= {
this.getDataAsync().then(data = {
Is it possible to export a module instance object?
module x from x;
export { x };
I believe this should be allowed. I'm not aware of a technical reason why
it shouldn't, and not allowing it would restrict some valid design options.
For instance, within a package I might have a module
The point I was making in the meeting was that arrow functions are a
syntactic convenience for a common case, not a general-purpose replacement
for all functions that need to refer to an outer this-binding. They are not
general-purpose because they don't support all the features of longhand
TLDR: We should consider deferring specialized syntax for exporting a
default binding until after ES6.
In the current draft, there are 3 ways to export a default binding:
1. Export a local binding with the name default:
class Parser { ... }
export { Parser as default };
2. Use
Good observation. However, if I were to simplify, I’d only keep #3. #1 and
#2 look more syntactically questionable to me (kind of abusing names as
keywords/markers).
#1 is the base case because it is completely general. Any IdentifierName
may appear in the as clause.
export { x as
#2 was removed at the hallway discussion of the face to face meeting. Do
you still think we should remove #3?
My only real issue with #3 is that it raises a footgun flag for me:
export default function parse1JS(code) {
// ...
}
parse1JS.foo = bar; // Surprise!
Although the import side has this one extra syntactic special case for
defaults:
import x, {y as z, ...} from ...
That seems really redundant. I assume mixing default import with
others will be an extremely rare case, and when really needed, can
easily be expressed as either
import
Jason suggests keeping the token stream and backing up. Another
alternative is remembering the source position of the start of the
parameter list and reparsing when the ambiguity and strictness is resolved.
Whether text, token, or AST based reprocessing is better is an
implementation
This is no different from
function f(x = function(y) { delete y }) { use strict; }
It is in the sense that in the case you present, you already known by
virtue of the function keyword that you are entering a maybe strict
context.
But I was able to program around it - not a huge deal.
OK. One last question: I'm reading that the strictness of arrow functions
is determined only the strictness of their enclosing context, and not by
any prologues inside of them. True?
x = { use strict; with (x) {} } // Not a strict-mode error
___
x = { use strict; with (x) {} } // Not a strict-mode error
Spec bug if so -- that should make the arrow function so stated have
strict code.
That would probably be the expectation, and I'm possibly just missing
something in the spec. It does add an extra degree of complexity, though.
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
___
es-discuss mailing list
es-discuss@mozilla.org
'yield' is already disallowed in generator function default initializer
expressions (although I was reviewing the latest spec. revision yesterday
and there may still be still bugs I have to fix in that regard).
The reason it isn't allowed is that the generator object is not yet
instantiated
But IIRC (and from reading http://people.mozilla.org/~
jorendorff/es6-draft.html, looking for LetOrConst uses), ES6 supports let
in all contexts, reserved word or not.
Yes, I see that now. Has anyone done compatibility-hazard analysis for
this breaking change?
;
let[a].foo() //
Implementation note: It is super obnoxious.
+1 for adding that note to the spec : ) j/k
It all just makes me wonder if we're better off saying: Forget the 'use
strict' prologue, it's foobar. For strictness, use classes and modules
instead.
In no way am I trying to recall a sailed ship
Thanks. I should have looked -- at this point es6-draft seems to have
almost all of the wanted answers. Great work, keep going!
Agreed, thank you Allen for bearing with me!
___
es-discuss mailing list
es-discuss@mozilla.org
Apologies for this remedial question, but I find the new grammar
parameterized around [Yield] to be confusing. If I understand correctly,
this is to allow yield within non-strict generators. If that's correct,
then why are non-strict generators a good idea?
Thanks!
function(a = yield+b) {
use strict;
}
Ah, thanks for pointing out the function-head issue. So for non-strict
regular functions, is yield allowed in parameter initializers or not?
___
es-discuss mailing list
es-discuss@mozilla.org
This makes for wtfjs additions, but they all seem non-wtf on reflection
(or did to us when Waldemar threw them up on a whiteboard last week). By
non-wtf, I mean anyone who groks that yield is reserved only in function*
can work them out.
The star after function really helps. ES5's use
So we parse it as an identifier, just as we parse duplicate formal
parameters. Then if we see use strict, we must post-process the parse
tree and throw an error. Kind of a shame, but there it is.
To use Waldemar's word, I wonder if that might get obnoxious:
function(a = function(yield
The handling of 'yield' in this case is no more obnoxious than any of the
other strict mode restriction that apply to those functions that are
defined in the parameter list.
Agreed. My Homer Simpson joke was just trying to point out that
(irrespective of `yield`, per se), post-validating
Thanks Allen, this clears up the yield situation for me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The other option (I say this bracing for pain), is to avoid potential
full-tree re-validation by applying strictness to parameter bindings only,
and not to default expressions.
This option might not be so bad if you consider that (a) code will
gradually be moving into implicitly strict contexts
Allen,
What's the rationale for not making generator functions implicitly strict?
Implicit strictness seems natural for new function forms, minus arrows.
Looking forward, I have a hard time imagining that we'll want, say, async
functions to be non-strict.
I probably just missed some discussion
The idea was to treat them as similarly to 'function' as possible, because
* is such a small syntactic difference
Makes sense, although on the other side you have a huge semantic
difference, little refactoring hazard, and `yield` already reserved.
Thanks again!
-
Validating default parameters against strict mode seems no worse in kind
(if not degree) than validating parameter lists against duplicates was in
ES5 days. Gross, but doable and I think better than leaving default
expressions non-strict.
Perhaps you're right. In addition to what we're
Perhaps you're right. In addition to what we're doing already in ES5 and
now ES6 destructuring patterns, I suppose you'd need to recurse into
default expressions and look for any bad `delete` expressions, any
WithStatements, and any bad BindingIdentifiers. And rinse and repeat with
any
I see that the Error constructor is designed to be subclassable. I can
create simple error types like so:
class ZenError extends Error {}
let err = new ZenError(abc);
However, I would expect that:
err.name === ZenError;
Such an expectation would be useful when determining how to
I think that the first of these has been established, there was a
suggestion raised about the third and I have no idea about the fourth. I do
however, admit that the patterns proposal doesn't sound to me like it has
enough to solve this use case, or that I understand how the two are that
Heck, why not just add async functions to the agenda?
There's:
- Promises, yay
- A well-establish use-case, which is awkward to implement without (as the
original post demonstrates)
- Strong syntactic precedent with C#
- Strong semantic cowpath with TaskJS
- Strong developer interest
- A year to
- A year to work out any kinks : )
No, you're wrong --
I welcome correction as always, but I would appreciate being able to post
to es-discuss without having to worry about this kind of backlash. Thanks.
___
es-discuss mailing list
Thanks - and thanks for pointing out the dependency on a scheduling
specification. 3, for real.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From the examples I've seen so far in this discussion, it's likely that
what is wanted isn't generator arrows, as much as syntactic support for
asyc functions. Such a function, would, among other things, insure that
all exceptions are converted to rejections, even exceptions occurring in
the head
It would be great to have await, but in the meantime having generator
functions would help male async methods tolerable. Await is ES7 at the
earliest, generator arrow functions could be in ES6.
Adding new features to ES6 at this point in time? I don't know...
Besides, with async functions,
Basically, as long as the outermost generator is
run by an async runner, both lazy and async execution of all nested
generators/iterators is possible.
Sure - it's the async runner part though (e.g. `spawn`), which is the use
case presented here.
async function F(p1, p2, ...pN) { /*...*/
Hi Mark,
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Over in Dart they have implemented zones.
http://api.dartlang.org/dart_async.html
{ zen }
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Basic sysadmin stuff.
To finish the thought, `done` and `WeakRefs` fail (a), and console-only
A well-known problem with Promises, as implemented in various Javascript
libraries, is that program errors are silenced by default. Consider the
following program, which simply makes an HTTP request and then prints out
the HTTP response headers:
Requiring early registration prevents the use of futures as value
containers; i.e. kicking off an operation and storing the Future somewhere
so anyone can use it at a later date.
One can always do that, provided that you register an error handler *before
your call stack is cleared*.
{ Kevin
Domenic,
First, your caricature of my position is patently ridiculous.
Second, can you or someone else offer a clear use case which requires
undecidable error handling semantics? I have asked for examples several
times and so far I haven't seen anything convincing. Usually that
indicates that
It has been shown that delayed registration, in general, is useful.
However, it has not been demonstrated that delayed registration of a
primary error handler is necessary.
If use cases have been provided, then please provide links. Otherwise,
let's not use ad hominem in place of logic.
{
This is trivial with Symbols:
let shuffle = Symbol();
Array.prototype[shuffle] = function() {...};
Only code that has access to the `shuffle` symbol may use the method:
let shuffled = array[shuffle]();
Unfortunately, such a construction will fail in a multi-realm (i.e.
multiple
Side note (sorry): I missed that PDF the first time around, but from what
I read it looks like good progress is being made. It feels like it's
coming together. : )
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
I think all we want here is make HTMLCollection interoperate better
with other lists. For new features we moved away from HTMLCollection
for the reason you mention.
What do you think an HTMLCollection @@iterate method should do? Iterate
like an array, or like a map?
{ Kevin }
I took Anne's cheeky lack of quotes around the div's id attribute to be
just good HTML minimal style :-P. No extension there.
In other words, I thought this was an argument against using @iterator
to name the unstratified iteration protocol trap.
Yes, it is - and it *might* be the
Anne,
Would you agree that HTMLCollection is an inherently future-hostile API?
That is, it is impossible to add *any* methods or properties to the API
without potentially breaking compatibility?
{ Kevin }
___
es-discuss mailing list
Whether you personally use it, for-in is a reality. Introspection of
objects happens, so if you ship a library that's putting meta-level
properties into objects it needs to make them non-enumerable to be robust
in the face of client code that uses for-in but isn't prepared to
understand the
In this case I doubt @iterator or @toStringTag should be visible. (And I
know there a better ways to test for empty objects, but for-in testing is
common enough...)
Thanks Andre! I fear this example merely begs the question of whether such
an object should be considered empty with respect
All the noise we made about Object.extend was unclear? From jQuery:
https://github.com/jquery/**jquery/blob/master/src/core.**js#L157https://github.com/jquery/jquery/blob/master/src/core.js#L157
Many similar functions, going back to Prototype's Object.extend:
Object.extend =
div id=@iterator/div
scriptalert(document.getElementsByTagName(div)[@iterator])/script
This is a good point, and one which I was trying to reason about (way)
upthread. This might do it - have to sleep on it, though...
{ Kevin }
___
es-discuss
I do not plan to switch to Map for string-keyed maps. I’ll be using
`Object.create(null)` instead.
Thanks, Domenic. I withdraw that aspect of the argument.
I'm still not quite convinced that objects-as-maps make a truly isolated
namespace necessary, however. I would be convinced by a code
You call namespaced strings more convenient than symbols, serves the
purpose equally well. These two things are obviously not equivalent --
namespaced strings are obviously weaker.
Obviously. I don't contend otherwise. I'm asking a different question:
does their added strength justify the
I think that your example _might_ do it, although I'll have to think more
about it tonight.
If so, then the justification for symbols at this point is based on the
dual use of JS objects as programming abstractions and as a key-value data
structure. Oh, javascript... : )
{ Kevin }
A solution that works is better than one that doesn't. We always knew that
patterns of proxies short of membranes would have abstraction leakage. This
is one. What is wrong with the stance: Live with it or use membranes,
I think I agree with this stance. Does that imply that we should drop
The way I see it, `invoke` (as currently specified) introduces new,
slightly incompatible function-call semantics, and doesn't really solve the
problem of transparent forwarding to targets with private state. Better
off without.
{ Kevin }
___
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and we have
not been able to fix that while maintaining other important semantic
requirements. If JS programmer have an expectation that they can usefully
write such
Thanks Rick, for writing up these meeting notes once again. Some comments:
## Symbols ##
As it currently stands, the only thing that symbols provide is an isolated
namespace for meta-level property keys. This assures us that arbitrary
string keys will not collide with any meta-level property
This seems like a non-sequitur. Symbols aren't meant to help with the
object as map use-case, and even if you tried to, they work terribly
for it. They're meant for the add an actual property/method without
collision use-case. Again, Maps seem like a non-sequitur here -
using a Map doesn't
Now, one might argue that using the string std:iterator (or equivalent)
would present a backward compatibility hazard for legacy code using objects
as maps. I'll have to think about that one...
Problem is polyfillability, and Map polyfill with O(n^2) complexity is a
loser in general.
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take
this fragment:
(1) function f() { doSomethingWith(this); }
(2) f.call(obj);
Presently, the expression at (2) grants the function
I've been only loosely following this thread, but I think Allen's proposal
has merit. If I understand correctly, it is extremely simple: provide
proxies with a hook into [[Call]], based on the `this` value.
{ Kevin }
___
es-discuss mailing list
Hi Kris,
Thanks for the details! This gives us an idea what a promise monitoring
feature might look like in a browser's developer tools. I think such a
feature would be really cool, but I believe that promise-using programs
ought to be debuggable using just a console. Indeed, for a non-GUI
It's not clear to me why this, or your `Promise.throw`, is better than
```js
somePromise.done(...)
// or
somePromise.then(...).done()
```
Not *much* better, I'd say, but IMO a `done` method which accepts a
callback overlaps too much with `then`, and a `done` method without a
callback just
401 - 500 of 952 matches
Mail list logo
