Recall the main objection was not the generativity of @names mixed with the obj.@foo pun
(after-dot). It was the usability tax of having to declare
private @foo;
before defining/assiging
obj.@foo = foo;
(in a constructor, typically).
Good clarification, thanks. Yes, the more important
Is 'super' currently limited to method bodies, excluding local functions?
super is limited to ClassBody
Yes, the question is about arrow functions in ClassBody.
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm
Is 'super' currently limited to method bodies, excluding local functions?
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that
With many new functional programming possibilities (like map, reduce,
filter, lambdas) there are many scenarios where the implementer should
use pure (or as I renamed it in another reply, side-effect-free)
functions.
Why should? What is the problem if people don't?
In the non-sequential
On 19 November 2012 13:04, David Bruant bruan...@gmail.com wrote:
I wish to point out a little thought on the topic of memory management. As
far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and references
between
On further thought, I'm not so sure. Consider this code, which creates a
directory if it doesn't already exist and then logs done.
return AFS.stat(path).then(stat = {
if (!stat.isDirectory())
throw new Error(Path is not a directory.);
}, error = {
// Path doesn't
Both then and fail return another promise for the result of the callback
var someData1P = query(q1);
var processedDataP = someData1P.then(function first(data){
return process(data); // if what's returned here is a promise
P, then
// processedDataP will be a promise for
Another idea: log such transformed errors, or automate matching of handled failed promises
against generated failed promises.
What we really need, as mentioned by Kris Kowal on Twitter recently, is the ability to
*un*-console.log something. That is, we want to log unhandled rejections for the
: http://rauschma.de
Blog: http://2ality.com
On 07.11.2012, at 00:42, Claus Reinke claus.rei...@talk21.com wrote:
I agree that promises should be standardized in Ecma-262.
Agreed. That would also offer the possibility to support promises
in syntax. In ES7 (latest), I would like to see something
I agree that promises should be standardized in Ecma-262.
Agreed. That would also offer the possibility to support promises
in syntax. In ES7 (latest), I would like to see something roughly like
{ ...;
let x - promise;
...;
}
(read as let x from promise), desugaring into
{
The set of values actually contained by the WeakMap at any moment is
non-deterministic, depending on the scheduling of gc. But this
non-determinism is non-observable. WeakMap.contains would make it
observable.
a) this concise elaboration should be part of the spec, to reduce
guessing about
I thought it was agreed that the function passed to
Set.prototype.forEach would be called with 3 arguments, the value, the
value again and the context object. This is so that one can use the
same function for Array.prototype.forEach, Map.prototype.forEach and
Set.prototype.forEach.
Yes, I've
When I explained __proto__ at JSConf, the first question was: “How
is __proto__ better than the ‘prototype’ property that all constructors
already have?”
|On the other hand, Axel's point is taken: the subject of 'prototype'
|is confusing. But this is only partly terminology; much of the problem
On the one hand, the point of eager execution was to make the execution
model simple and consistent with corresponding IIFE code.
When we switch from scripts to modules, it makes sense to switch
from execute-as-encountered-for-side-effect to resolve-dependencies-
and-extract-exports. The
about their work*,
the more information we'll have;-)
Claus
(*) I am always surprised to see attempts with commercial
tools for developers (as opposed to commercial support/service
for free tools, or commercial tools for non-developers).
On Oct 16, 2012, at 5:12 AM, Claus Reinke claus.rei
With ES6 engine compatibility still looking somewhat red
http://kangax.github.com/es5-compat-table/es6/
transpilers are not just a useful way of communicating ES6
development (avoiding surprised audiences later [*]), they also
provide relief for those who keep reading here about new
features
Have you found the actual usage of length in node libraries to
enforce this sort of signature testing? I was poking around and
haven't found it.
Side question: has tc39 tried to contact any of the research groups
that specialize in large-scale repository mining?
Usage questions here are
What was the story wrt subject?
The Note in ES5.1, 12, Semantics (FunctionDeclarations as Statements)
used to be unproblematic as this non-portable feature could simply be
avoided.
It also was unproblematic when ES.next still required opt-in, as old
implementations would then balk before
* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
As I understand it, this goes back to lazy parsing
http://ariya.ofilabs.com/2012/07/lazy-parsing-in-javascript-engines.html
which, in turn, seems to
.
On Mon, Sep 24, 2012 at 4:08 PM, Claus Reinke claus.rei...@talk21.comwrote:
Right. What I'm suggesting isn't that you'll be able to prevent the
global
from being augmented, rather that if your goal is to take an *already
well
behaved* library and wrap it with modules, that's possible
Right. What I'm suggesting isn't that you'll be able to prevent the global
from being augmented, rather that if your goal is to take an *already well
behaved* library and wrap it with modules, that's possible.
Aren't Module Loader Translation hooks meant to help with this?
0. yes to (for|if)* - also for generator expressions
1. Array comprehensions with for/if do not look very readable -
the generators and filters seem to merge into one blob of text.
[x*y for x of range(XDIM) if x1 for y of range(YDIM)]
While syntax highlighting and/or formatting can
Thanks everyone for your feedback!
I certainly learned a thing or two, but the majority opinion
and information seem to be:
- further divergence is in the cards for AS and ES
- AS and ES are already so different that, wrt input to ES
development, AS has no special status over other
at 1:30 AM, Brendan Eich bren...@mozilla.org wrote:
Claus Reinke wrote:
Hope this isn't politically inappropriate here;-)
1. Flash is dying as a browser plugin, but otherwise still alive,
especially with compilation of Actionscript to native code [2,3].
2. Adobe has been growing support
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on privately
named methods for its functionality:
...
Neither the destination object nor the library function mixin has access
to the private name, and therefore the
Hope this isn't politically inappropriate here;-)
1. Flash is dying as a browser plugin, but otherwise still alive,
especially with compilation of Actionscript to native code [2,3].
2. Adobe has been growing support for HTML/Javascript options.
3. Actionscript is based on an old ES draft
Also, the monotyped approach is easier to optimize, all else
equal. See http://qfox.nl/weblog/265 for testimony about this
(find JIT mixed messages).
Is there a message where JS implementers and optimization-
dependent JS users can talk to each other?
Micro optimizations, even if drastically
Finally, I do have a way that we could put the cloning of private
named properties by := under programmer control.
Giving objects control over how they appear to := and other
Object.extend variants sounds like a good idea.
Note that private named properties are never enumerated or
exposed
But it also made me realize that by default, destructuring returns
unbound methods.
...
Agreed that this is an obstacle. With operators, one could have a
convenient binding selection, but the destructuring case needs a
separate solution.
Why does it need a separate solution? Especially if
need to communicate that they are not limited to strings, though:
template parameters and tag results can be arbitrary ES objects/values.
I chose template string over string template to emphasize that it was
a template that was expressed as a string rather than a template for a
string. That
But it also made me realize that by default, destructuring returns unbound methods. It's perfect
for the above use case, but may be annoying when you wish to extract functions bound to the object
they're extracted from:
var o = {a:1, f: function(){return this.a;}};
var {f} = o;
[argh, unhelpful hidden key-combo led to premature send]
But it also made me realize that by default, destructuring returns
unbound methods. It's perfect for the above use case, but may be
annoying when you wish to extract functions bound to the object
they're extracted from:
var o =
let tmpl = html`
table
$for address in addresses ${
html`tr${first}/trtr${last}/tr`
}
/table`;
let tmpl = addresses = html`
table
${addresses.forEach(address=
html`tr${address.first}/trtr${address.last}/tr`
).join('\n')
}
/table`
let tmpl = addresses = html`
table
${addresses.forEach(address=
html`tr${address.first}/trtr${address.last}/tr`
).join('\n')
}
/table`
Yes. But you need to say .map( rather than .forEach( above. See
http://wiki.ecmascript.org/doku.php?id=harmony:quasis#nesting.
Context:
References are a specification-level construct that has no
language-level representation in current ES. Reifying
References as objects has been deemed troublesome/
inefficient for implementations.
Problem:
The lack of reified References is a blocking issue when
As noted, we're moving away from References in the language.
l-values as function parameters are still going to be useful,
for abstractions involving assignment operators.
Macros are out there but the better way: you want to abstract over syntax, not runtime lvalue
semantics.
Useful macros
Are macros really the only way to get around JS's peculiarities
when trying for user-defined operators and control structures?
Argh - I just noticed that even macros won't be sufficient.
Assuming we had function-like definitions that inlined/expanded
their bodies at their call sites, textually
At least, I can't think of a way to avoid reevaluating the left
hand side operand - if I assign it to a temporary variable, it
no longer is a valid left hand side for an assignment.
The trick is to specialize as all competitive JS engines do today to
avoid references:
id op= val ~~~ id =
On the subject of 'exporting one value', there are a few things to say:
1. It's been asserted repeatedly that libraries that export 'just one
value' are a better design, but while this is excellent style in lots
of cases, I don't think a persuasive case has been made that this
should be the
Being able to access the export object from the module object enables a
pattern we use locally, which is roughly
require(myModule).configParameter = xyz;
..
exports.errorReporter, exports.configParameter are then used heavily within
the module -- normally, they are not even set by the user,
[I've elided some points and comments: I was trying to summarize
what seemed to me the core issues in this discussion; if my summary
was unclear, it won't help to add more text; if my summary was clear,
but the disagreements persist, adding more text won't help, either]
Here I've come
We've already been looking at value types, proxies, and objects for a
while. The latest,
http://wiki.ecmascript.org/doku.php?id=strawman:value_objects, does
not expose user-defined operators, to separate concerns and limit
scope, but user operators are doable.
I know, but previous strawmen
At the same time, new infix operators keep getting proposed.
Where?
Here on es-discuss, and on the wiki?
symbolic:
|, ??, ??=, ?., .=, .{
named:
modulo, div, divmod, has, extends
I've probably missed some - there seems to be a steady
trickle of such proposals.
Claus
?? and ??= are short-circuiting, they do not fit into a eager
evaluation calling convention.
Actually, that isn't even the worst issue. Since operators aren't first
class, the desugaring could wrap arguments in (arrow) functions
at the operator call sites (I've got a variant of infix.js that
If you want to export a bag of functions, then put the functions on an
object, and export the object.
It *is* making it trickier to figure out how to add types and macros,
but I'm less excited about those features than I am about making our
existing problems easier to solve.
It's not trickier,
is obj
undefined
{ x: 1, y: 0 }
Hope you like it,
Claus
--
From: Claus Reinke ..
Sent: Wednesday, July 11, 2012 10:01 PM
To: es-discuss@..
Subject: suggestion: mapping symbolic infix ops to binary functions
The discussion of re-interpreting
function map(f) {
return this.reduce((result, value) = result.concat([ f(value) ]), [])
}
..
var map = (list, f) =
list.reduce((result, value) = result.concat([ f(value) ]), [])
Not sure I got your motivation, but would this help?
function fn(f) { return f(this) } // provide 'this' as
Ok, this will work fine using the multiple script tags approach you
showed.
Actually, I no longer think that third approach will work: there
is no reason why the load callback in the first script element
should run before the code in the second script element, so
'main' will not be available
We could try to have our cake and eat it, by extending the pattern
language with prefix-! or prefix-?. Which prefix depends on the
choice of default behavior, based on ranking of the two
equivalences. Whatever that ranking, does this make sense so far?
Sure, I'm all for that. As
To outline the disconnect, consider this simple static module
chain for a dummy project ab I might like to use:
// a.js
export var a = a;
// b.js
import {a} from 'a';
export var b = a+b;
To use this in my main code, I again use static import
// main.js (or perhaps a script
Similar to the dummy project sources, the nature of the loader
is not important to the concerns expressed in my message (in
the comments).
I disagree -- it's not possible to know what the requirements are, how
else they could be solved, what the current state-of-the-art is, and
how common this
When reading Dave's post on Static module resolution [1],
the section on Future-compatibility for macros struck me
as a case where users/proponents of different module systems
seem to be talking past each other. All agree that there is an
important feature, but the approaches differ so much that
When reading Dave's post on Static module resolution [1],
the section on Future-compatibility for macros struck me
as a case where users/proponents of different module systems
seem to be talking past each other. All agree that there is an
important feature, but the approaches differ so much that
Ultimately, I'd like to have both:
- irrefutable matching:
- refutable matching:
One is a syntactic convenience for selection only, the other
for selection plus structural tests (actually: behavioral interface
tests, see below). Both have their uses.
This suggests having pattern syntax
let * = Math;
This is dynamic scoping. The difference between import * and let * is
that
the former is statically scoped, and the latter is dynamically scoped.
I'm sorry, I'm not entirely sure what static scoping means in the context
of JavaScript. Could you clarify? Does it mean that it's
My own favourite approach would link ASI to layout/indentation,
and introduce warnings instead of breaking code:
1 if ASI kicks in, but indentation suggests statement continuation,
issue a warning
2 if ASI does not kick in, but indentation suggests new statement,
issue a warning
I did
var a = this.a // here no semicolon will be auto inserted
[1,2,3].forEach(function(){
// do something
})
Consider
arr.map(function(..){..}) // no semicolon wanted here
[..]
(function(){
//do something
})() // here no semicolon will be auto inserted
(function(){
If you look back on this thread you will see an example extracted from
the case that caused me pain. In the real life case I was using Kris
Kowal's Q_COMM library, which builds on Q and is quite sophisticated
code.
I added a function to a Q_COMM object. Later when I called the
function I got an
That is all within the purview of a standard FFI to address. For
instance, the Haskell FFI
You can stop right there. We have one major Haskell implementation.
You mean like there is only one major browser implementation?-)
Just because one implementation currently has the most steam,
that
Different native-code compilers and OSes (not always tied, btw) will
choose different FFIs, depending on local macro- and micro-economics.
Even today we have a choice between calling conventions on Windows (not
always obvious; Rust has changed at least once in its young life).
That is all
Once we have modules, should we have a place other than ECMA-262
to define standard host-environment libraries that ship with browsers?
Like the DOM?? ;-)
..criteria for which libraries might be within the prevue of TC39:
* it requires extensions to the base language syntax or semantics or
What should be the output of the following code?
(function(){
try {
throw hi;
} catch (e) {
var e = ho;
var o = hu;
var u;
console.log(e);
}
console.log(e,u,o);
}());
It seems clear that the first console.log should output 'ho'.
Implementations seem to disagree on the second console.log,
it appears that the SpiderMonkey AST has emerged as a de-facto
standard.
Really? I guess there are many more users of Uglify and Esprima is
growing fast. Personally I never heard of any non-Mozilla uses of the
SpiderMonkey API, but perhaps you can point to some.
I was merely stating my
Inside the catch, the catch-scope is first for reading and writing.
In practice (as in: what implementations permit; not: what is used),
there is also this variation:
try { throw oops }
catch (f) {
function f() { console.log(f) }
console.log(f)
}
console.log(f)
This isn't permitted in
On May 14, 2012, at 2:57 AM, Claus Reinke wrote:
What should be the output of the following code?
(function(){
try {
throw hi;
} catch (e) {
var e = ho;
var o = hu;
var u;
console.log(e);
}
console.log(e,u,o);
}());
It seems clear that the first console.log should output 'ho'.
Implementations
Looking through the destructuring proposal
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
there seems to be no mention of 'as' patterns. In typical pattern
matching constructs (SML, Haskell, ..), 'as' patterns allow to name
a sub-object while continuing the match for its
I've found it quite useful in Clojure/Script and I'm sure folks who have
encountered the feature in the ML derived languages would agree.
Indeed, all of the pattern-match-supporting functional languages
I've used also supported 'as'-patterns in some form ('var@pat' in
Haskell, 'var as pat' in
So, assuming Math has no dependencies (just to make this shorter), the
sequence of events:
* Load Foo, convert to AST, find from usage.
* Load Math
* Compile Math
* Evaluate Math
* Inspect Math's exported module value for properties
* Modify the compiled structure for Foo to convert import * to
I just noticed that James' original email had two more items:
* The 'Math' module is evaluated before Foo is evaluated.
* Only the properties on Math that are available at the time of Foo's
execution are bound to local variables via the import *.
which puts it in line with the first option I
To me, the ability to emulate the feature additions so closely in
library functions suggests that some variation of fn and rec should go
into the standard library instead of adding such features to arrow
functions.
Why wouldn't we add arrows too? There's a usability and an
Your point about synthesizing dynamic-|this| given lexical-|this| forms
is good. It seems to me having fn, rec, and = is therefore best. What
am I missing?
That is my current state of thinking, too.
Until I started thinking about performance:-( With current
implementations, at least, using
Other than the JQuery style misuse of this, what are the
use cases? If you want to bind this, why wouldn't a method
invocation on an objet be involved?
The ES array loops accept an optional this parameter to
be used for the loop callback.
It is up to the caller of the forEach to provide both
foo(a, b, ...rest)
vs
foo(a, b, rest...)
Which is clearer?
The former suggests a special construct that may have a name,
the latter suggests a variable of a special kind. But there isn't
anything special about the variable (a or b could be Arrays, too),
so I find the suffix form
Btw, why three dots? I always find myself writing two dots..
Presumably because three dots make an ellipsis, which has roughly
the meaning we're aiming for here.
True, and I admit to omitting that third dot in natural language
as well. But in the context of JS, if I think of ... as the
I agree that leading |this| could be important for dynamic
non-method use-cases, but those are relatively rare (let's
not discount JQuery, but again, it could use long functions
and survive). We could put leading-this-parameterization
on the agenda for May, but we'll have to be careful not
Libraries will need to work in old world browsers for a few years.
Possible solutions:
a) Ask libraries to provide a lib.es-next.js version of themselves in
addition to the old world version, so that compile time linking with
new module/import syntax can be used.
b) Have a way for the library
I think you misunderstand the relationship between what Dave said, and
The purpose of my questions is to remove misunderstandings -
it is entirely possible that some of them are on my side!-)
If you have dynamic modules, you can't use them to export any
compile-time
constructs, like macros,
Today I have noticed one interesting remark from Douglas Crockford on
arrow functions: you will need to use the old functions to write
self-recursive functions -
http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this
Is that really going to be the case ? I was so much looking
If you have dynamic modules, you can't use them to export any
compile-time constructs, like macros, static operator overloading,
custom literals, or static types. If you load a module at runtime,
then it's too late by the time you actually have the module to use
it for anything at compile
Is there any particular reason optionally dynamic `this' got ditched from
the current arrow syntax proposal? It's one thing that, I think, would
make it more useful than just being used for inline callbacks.
You can get that back without changing the proposal (ES6 comments,
ES5 code):
// wrap
To get
recursion at expression level, you can always define your own
recursion combinator. Something like
// ref(f) produces f(rec(f) modulo some eta-expansions
let rec = (f)= (..args)= f( (..args)=rec(f)(..args), ..args )
Applying rec to an arrow function would supply the latter with a
DaveH's presentation about module loaders
Shouldn't any newly designed async loading APIs support promises?
No, for the very simple reason that promises have not been standardized
and won't be in ES6.
Understood. Though this leaves us with:
- use of module loaders could profit from promises
DaveH's presentation about module loaders
Shouldn't any newly designed async loading APIs support promises?
For ES proposals, promises seem to be burried in the concurrency
strawman.
DaveH: Imperative module replacement example:
@websockets exists as version 1. An implementation wants to
2) Frameworks that currently use |this| as a general parameter passing
mechanism may find that there are better ways to pass that data, given
arrow functions and the ability of users to take advantage of lexical
|this|.
3) There's nothing wrong with long-hand, if that's what you want.
How
The ambiguity between a block body and an object literal expression body,
which we would prefer to resolve in favor of object literal. The solutions
considered before this edit were:
* http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
* Two-token lookahead restriction per
(function () {}) creates two object, not one.
I'm not sure what you meant here. ..
the empty object for the function's .prototype
currently seems to elude me in all its forms..
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
Thanks, I did catch up that far on the thread, but Allen reiterated the
point he'd made months ago: you can't hoist *and initialize* the class
declaration as you can a function declaration. Rather, class decl is
like const decl. That was my point.
If hoist means only the binding, with a TDZ
So I gather that the dynamic case would look like:
system.load(jqueryPath, function(m) {
system.load(shimLibPath, function(n) {
system.load(corpLibPath, function(o) {
system.load(myLibPath, function (p) {
import * from m;
import * from n;
the special case in | is an artifact of function manipulation being too
inconvenient in JS, and of | being limited to literals (which is an
artifact of object cloning being considered tricky).
Even more so it is a matter that array, function, and RegExp objects
have special semantics (internal
2. Also we are not losing static binding by having the names injected
by static syntactic forms depend on control flow dynamics.
When statically checkable constraints meet dynamic load/eval,
it isn't necessary to have a strict static/dynamic split. It would be
possible to adopt a multi-staged
- would it make sense to name the constructor after the class
(avoiding 'constructor' and 'new')?
That seems to be a 'no', then:-) It might be useful to document
such obvious but rejected options, with counterarguments:
- repeated name
- readability/search concerns (constructor determined
- could we think of hoisting a class as hoisting its constructor
This would be a new kind of Temporal deal zone. I don't think
we need it. Can you show a use case were the current proposal
(class X{} scopes just like const X;) doesn't work.
Thinko of mine, sorry. The reasoning was that
Btw, another question that has bugged me lately: with 1JS, what
happens when I do a sloppy-mode direct eval on a program string
containing a module declaration? In global scope? In local scope?
It's a good question, and one I've thought about some. This could
use some whiteboard time -- let's
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're
The example you gave produces a constructor that wraps a handful of
instance method definitions along with several function declarations -
which I'm arguing could just as easily be outside of that function
declaration, but inside of an IIFE.
There are two issues here:
1) “Private methods”
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to interpret
(p | obj) simply
The nicest proposal I have seen has been written by David Herman:
https://gist.github.com/2011902
Commenting on the gist proposals:
G1. shorter function syntax: (..) - {..}just sugar for function
(..) {..}
This looks like a strawman, not solving the issues.
G2. lambdas:(..) =
Surveying other libraries would be helpful.
Yes - enough guessing - I'll do my best to do some counting with different
libraries (both for DOM and for nodejs) and report back some numbers. Erg
- busy work : )
Surveying is useful in the sense of visually comparing code versions
with/without
Like many others, I would like to have very lightweight function definition
and call syntax, because those are the cornerstones of functional
abstraction.
This transcends classical functions, and would ideally include the ability
to
*define*, in userland, many of the control-flow constructs
This may of been beaten to death, so sorry to bring it up again :)
To the extent that design rationales are not recorded on the wiki,
repetition is hard to avoid. There have been just too many variations
in the mailing list archives to make catching up just from there realistic.
Whenever I've
101 - 200 of 302 matches
Mail list logo
