Another lingering objection to arrows is this-binding (= vs. -).
*If* it is possible to make 'function'-free functions work, then how
about dropping the implicit bindings for 'arguments' and 'this' for
the short form? Then the 'function' keyword would be a modifier
on the short form, to
Just saw this wiki update (*)
http://wiki.ecmascript.org/doku.php?id=harmony:modulesdo=diff1328732818
and this sentence:
If there is a conflict between the names from two distinct imports,
and exactly one of the imports uses the ''*'' form, then the other
import takes precedence.
Okay, that wasn't clear to me from the meeting notes. In general,
I've completely lost track of what ES6 is going to look like: too
many variations and re-designs in the mailing list threads, no way
for me to distinguish member preferences from committee
agreements. As the wiki no longer seems to
Btw, how does versioning work across eval? If I have a function body with
an eval in it, will the body/eval run as in ES5 or as in ES6? Will that
change if the body or the eval contain ES6 features? Will ES5/ES6 scripts
be able to eval ES6/ES5 code?
On this very thread we are hashing out how
I bet the mode was what got Sam's attention (mine too) in your
classic mode. We are not making hard mode walls or version opt-in. No
engine will have a mode enum that must be advanced (implicitly or
explicitly) and checked in order to tell what to do in unversioned
script. Or so we think!
I think use fn; (real pragma syntax), with the low-precedence
assignment-expression fn (params) assign-expr production, wins. What do
you think?
Having fn would be sweet. For many kinds of pragmas, it would be great if
one could configure these per project (or per directory). Then one could
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable
objects. Not just to set .prototype, also to decorate with ad-hoc and
meta-data properties. Freezing is not wanted by default.
Another example: when
So I'd have to write
use version 6;
module {...}
instead of just
module {...}
even though there's no backward compatibility issue? That's just mean! :-|
Why? Assuming that modules work out, they will be in ES7,8,.. as well.
So, 'module' isn't sufficient to identify ES6. At best,
if current construct is in ES6-only, abort current compilation and
restart from beginning, starting in State ES6
Basically using any ES6 features makes it an ES6 program. Using any
ES5-only feature makes it an ES5 program.
Combining ES5-only and ES6 features results in an invalid
Considering all that, I can't help feeling that having a separate mode
is cleaner, simpler, and easier to use. I think it also has more
potential for providing a robust foundation for future evolution of
the language.
This last point -language evolution- is something that Haskellers
have quite
From the early drafts of a standard library
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
it appears we are headed for an import name clash between
Object.keys and @iter.keys - they cannot both be available as
plain keys.
Object is not a module, so there's no clash. Lots of
Recently Claus Reinke proposed some alternative that I think feels is
so much more natural and simpler than | or beget:
..
.. re-interpretation deleted ..
Ahem;-) Glad to see my proposal noticed, but what I really
suggested, in
motivating | as structure representation, not operator
https
[btw: http://wiki.ecmascript.org/feed.php still gives me
url-encoded links; I thought that was meant to be
fixed by a wiki upgrade?]
From the early drafts of a standard library
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard
it appears we are headed for an
If I may, two suggestions: For longer posts, an executive summary
with the main points might make sense (not sure if I’m always
doing this, but I should). And if you can, a greater “column width”
for your hard line breaks would be nice, too. I checked in Emacs
where I’m happy with the column
Embedded spreads is already in the ES6 draft for both array literals
and argument lists. I'm not at all sure that embedded rests in
destructurings are such a good idea. Just to start with, what does this
mean:
[a,b,...r,c,d = [1,2,3]
..
This sort of destructuring is not real pattern
This sort of destructuring is not real pattern matching. ..
I think this is the important point. Many of us who like destructuring
are still being mislead by the name, and by our experience with proper
pattern matching constructs.
You just used a different term, pattern matching, than
To keep this thread from getting off-track: I am talking about
patterns as a common ground between ES.next spec writers
and JS.current coders. Focusing on patterns now would help
to get JS coders involved in checking current proposals for
consistency/edge cases, instead of leaving that burden
We use Google Postini in concert with Mailman. Postini needs to
be told sometimes. If you don't see mail get through, mail
es-discuss-ow...@mozilla.org about it.
/be
While that has helped usually, in this particular case my email to
es-discuss-owner (19.10.2011) also disappeared without
for own (i in o) {
body
}
What happened to @iter.keys and 'for (key of keys) {}'?
http://wiki.ecmascript.org/doku.php?id=harmony:iterators
Claus
http://clausreinke.github.com/
http://clausreinke.github.com/js-tools/
___
es-discuss mailing
In the following declaration, what should be the value of z?
let [z,y,z] = {0:0, 1:1, length: 2, 2:2};
and there I was, thinking I understood more than half of JS..
Since this was new to me, I referred to the spec. Here
strikeis my reading/strike are my readings:
The rhs is an Object, but
In .. an ES5/strict environment in which all primordial built-in objects
are transitively frozen, ..
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) {
// dynamic language
Object.freeze = function(obj){return obj};
You imply that this is not intended, so I can show it without spoiling
the fun. I was surprised that this works.
Since the primordials are already frozen, this assignment fails.
Yes. It just re-emphasizes the need to be the
I'm not just talking about implementors, either. Some users
will want to know d.m isn't going to change. They may not
want to know that it's b.m, mind you -- they simply won't
want that c.m assignment to be legal, or else if they do
support such a thing, they don't want it to affect d's
The only thing I find off the mark is the typography of |.
In light of this, and of the anti-grawlix reaction among
many people, could we revisit an infix operator used in
restricted productions with [no LineTerminator here] on
the left of the operator contextual keyword?
Am I the only one
But I am doubtful that that lightness results in better productivity.
Typing is not where we spend the bulk of our time.
Good language designs tend to have light syntax (but
not all light syntax languages have good designs).
The reasons have more to do with reading, and mostly
with thinking
Have you considered moving the spec drafting to a revision
controlled system, such as git? Michael Smith maintains an
annotated and hyperlinked version of ES5.1 here
http://es5.github.com/. A system like this would certainly
make your maintenance tasks easier, in addition to facilitating
a
[sorry for the incomplete message earlier - keyboard glitch]
Have you considered moving the spec drafting to a revision
controlled system, such as git? Michael Smith maintains an
annotated and hyperlinked version of ES5.1 here
http://es5.github.com/. A system like this would certainly
make your
There is a lot of abandon-ware in open source, ..
Too true. And, for JS tools, a development I've been watching with
increasing concern (development fragmentation coupled with
scarce developer resources leading to project starvation).
It is perhaps a necessary learning experience that new JS
As a detour from controversial language design issues, I was
wondering about opportunities to improve the ES spec usability:
- source availability: could the sources please be made available,
preferably in easily processed form, on github?
For draft standards, that would allow tracking
You mean by deprecate what, exactly?
Web JS is full of var. Making any attempt to migrate a big
hunk of it to ES6 require replacing all 'var' with 'let' is a
huge tax, since scoping works differently.
Ok, how about saying if you use 'let' in a function or at top
level, you can no longer use
Just walk the object graph starting from the root object and let the
set of all reachable symbols be A.
Load jQuery
Walk the object graph again letting the set of all reachable symbols be
B.
The public API of jQuery is then (B - A).
That's works fine under 2 conditions:
1. You're willing to
class Point {
var x = 0;
var y = 0;
distance(other) {
return Math.sqrt(x * other.x + y * other.y);
}
}
it is very tempting to think that var x and var y are in scope.
Would the following analogy with modules help?
Think of 'this' as
- the export object of the constructor method
It's different when you have syntax:
-
var o = {};
var a2 = o | [1, 2, 3];
-
Here, the array syntax literal guarantees (since ES5, not in ES3!) that
a native array is going to be built. Same goes for function(){} or any
object created with reliable syntax, so the parser can both safely
On the subjects of code navigation and DoctorJS as a basis for tools:
- Jump to the definition of a method/function.
..
- Find all invocations of a method/function.
..
I'm in the process of adding scoped tags support to DoctorJS, so that
in Vim you can also navigate to local definitions and
There are some half dozen or more papers on Javascript type inference
or static analysis (hmm, is there a central wiki or bibliography where
we could record and collect such JS-related references? should I post
here what I've found so far?).
For as far as you haven't already, I'd love to see
Improved, statically checkable, types would also help mitigate
Javascript's silent failures (silently breaking code when trying to
refactor, fixing bugs, or adding features). Unless the type system
is fairly advanced, type safety only expresses a thin veneer of
invariants, but coverage is total,
I'm hopeful that type inference combined with class syntax and
an (eventual) traits system will get us there, so that you can use
structural type tests for enforcement and that the IDE can get the
benefit of hints through inference.
Improved, statically checkable, types would also help mitigate
.. the key extensions I used in the collections experiment are:
..
* the | operator -- defines the [[Prototype]] of a literal
* the .{ operator -- extends the LHS object with properties from an
object literal
How do these two relate to (non-destructive) object extension operators
[1]?
The name resolution rules we agreed to permit mutually recursive
functions without hoisting (or you could view those rules as hoisting
everything):
let f1 = function() {f2()};
let f2 = function() {f1()};
f1(); //happily recurs until it it runs out of stack
Sorry, I seem to have missed that
I think there is a (usually unstated) desire to also test for
ES.next features that may also start to show up as extensions
to ES5 level implementations. For example, generators in
Firefox. You can't depend upon modules in such situations.
For me, the issue is that ES engines tend to
How about rest and spread, or de-structuring? We are
going to use non-eval detectability as a ECMAScript
extension design criteria then maybe we do need a less
ad-hoc scheme for feature detection. It wouldn't have
to be all that grand...
Even less grand ones such as the DOM's
Dear all,
we have seen examples of how to define control-structure
abstractions via block-lambdas (and Smalltalk blocks), including
non-local returns out of user-defined loops.
I'd like to provide an example of how to do something like this
with JS, using only the proposed syntactic sugar for
The discussion of parser APIs had a side-thread on language
versioning which I'd like to raise separately, for those not
following the parser discussions. I include the relevant
context, then continue the thread below.
But there are also tough questions about what the parser
should do with
the AST API strawman ..
It hasn't really been championed so far. I was concentrating on
other proposals for ES.next.
So it was just timing, not behind-the-scenes disagreements. Ok.
- it does not support generic traversals, so it definitely needs a
pre-implemented traversal, sorting
I don't think we have any consensus within TC39 WRT
whether such an API should be part of some future version
Ecma-262. Personally, this sounds like library functionality
that in the future might manifest as a module. I think we
need to draw a line at adding very many more such libraries
I guess the summary would be: I don't think Tennent's principle
of abstraction can be meaningfully applied to control flow when
your abstraction can survive the control flow that created it.
The success of such an abstraction for building control flow
abstractions in Smalltalk is a good
Javascript data structure operations: some of the APIs are imperative,
some are functional, some are mixed. Having functional equivalents
to all imperative data structure operations is necessary to support
expression-oriented programming over constant data structures.
imperative here refers to
Dear all,
following the recent suggestion here that github might be a
more suitable forum for kick-starting proposals than this list,
I've put together a proposal draft on simple paren-free function
calls and definitions:
https://github.com/clausreinke/jstr/tree/master/es-discuss
You can find
list, but if there are
any particular improvements/fixes that would help you or others
here, knowing about them would influence my priorities.
Thanks for your interest,
Claus
From: Claus Reinke claus.rei...@talk21.com
To: Kam Kasravi kamkasr...@yahoo.com
Cc: es
Hi Kam,
I've been experimenting with pegjs - which generates a parser
based on the ecma-262 5th edition grammar.
yes, pegjs [1] and jsparse [2] were the alternatives I had been looking
at. pegjs is probably a bit ahead when you just want to use the parse
result; I chose to build on jsparse
Hi Tom,
I just wanted to provide a bit more context on our Ometa experiment:
our goal was to build an executable parser whose definition was as
close as possible to the BNF in the ES5 spec, which worked out fairly
well. The main purpose of the tool was to be able to quickly experiment
with
tl;dr:
- JS-based PEG + ANTLR as a route for ES grammar experiments
- would like to know about route viability and alternative routes
If OMeta's should really be slower than similar parsers, and
the grammar-optimizing side is covered by the authors,
perhaps there is room for old-fashioned
Mark and Tom used Ometa for http://code.google.com/p/es-lab/
http://code.google.com/p/es-lab/ -- slo-o-o-o-w.
OMeta does do memoization, but it's still slow ;-)
I'm curious: what level of slow are we talking about here?
A basic memoing top-down parser for PEG-style grammars
with good
ECMAScript doesn't curry its function declarations. A function does take
all its arguments at once (and not as a tuple value), and since we can
even supply too few or too many arguments when calling a function, trying
to
mimic SML will only bring pain.
I thought so, too, for a long time. But
This is just a last-minute plea, given that the proposal freeze is
apparently imminent: could the committee please reserve a slot
for solving the readable monadic coding in Javascript issue -
it needs no semantic changes, only syntax, and combining
technical aspects of existing proposal might
Because the LabelledStatement changes in
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
restrict labels to prefix only LabelUsingStatements. I was
addressing the backward incompatibility here: ES1-5 allow
useless labels. You seemed to think that incompatibility was
://libraryinstitute.wordpress.com/2010/12/01/loading-javascript-modules/
[2] Functions, Frames, and Interactions - completing a
lambda-calculus-based purely functional language with
respect to programming-in-the-large and interactions
with runtime environments, Claus Reinke, 1998
http
the other is a much more radical change to the way
the language works, which I'm not altogether
convinced is a good or useful thing.
It's essential to the control abstraction programmability.
Take a look at the examples. .. Return from a block in JS
today returns from the enclosing function.
The top-down approach by default is to parse a cover grammar
until an unambiguous decision point is reached, then depending
on the decision, rewrite the AST (e.g., to make a labeled statement
in a block instead of an object initializer).
A somewhat less intrusive way to disambiguate
For a presumed-done area, there has been a lot of activity
in parser research recently, partially fueled by IDEs and DSLs
(model-driven development with good generated tool support).
For grammar spec purposes, it might be interesting to look
at self-applications of these techniques (IDEs for
I think modules are a construct that evaluates to an
object is the wrong way to think about them. Syntactic
modules are a second-class construct that is not an
expression. You can reflect on modules at runtime,
and that reflection is provided as an object, but that's
because almost all
Ok, final and most delicate part of the mission here:
allow (v) - {k: v} and even - {} to return objects,
not make useless block statements.
..
Thanks to Doug for pushing on this idea. I believe that it is
sound (still to be formalized and tested mechanically) in a
bottom-up parser.
The
ECMAScript has a large set of problems. ..
- fixing ECMAScript's oddities would be worth a language
revision, even without adding anything new
This is a mistake. The Web does not permit stop the world
and fix all known bugs. Neither users nor competing browser
or server-side software
7:06 PM
To: Claus Reinke claus.rei...@talk21.com
Cc: Douglas Crockford doug...@crockford.com; es-discuss@mozilla.org
Subject: Re: Function Syntax
On May 12, 2011, at 7:42 AM, Claus Reinke wrote:
ECMAScript has a large set of problems. ..
- fixing ECMAScript's oddities would be worth a language
ECMAScript has a large set of problems. I think that the fact that
'function' has eight letters is at the bottom of the priority list.
- fixing ECMAScript's oddities would be worth a language revision,
even without adding anything new
- ECMAScript's oddities have been deployed, resulting in
Background assumptions:
Fixing ASI, as desirable as that may be, is not going to
happen soon. Neither is the transition going to be quick
if/when a better alternative emerges, as existing ASI usage
patterns need to be supported.
However, these usage patterns are currently not
function bodies extend as far as possible **
I see. So, a function body would be just like an if-block or loop
body. One full statement, or a block. There is precedent for that in
the rest of the language. So, then, this case:
x = function () y; z
would be:
x = function () { return y
Consider this: w = (x)-y || z
That code is not obvious at all. Which of these would it be?
1: w = function (x) { return y } || z
2: w = function (x) { return y || z }
It seems to me that there must be some sort of delineation
around the function start and end.
But such delineation does
relating to
http://wiki.ecmascript.org/doku.php?id=harmony:generators
Claus
Roshan P. James and Amr Sabry.
Yield: Mainstream Delimited Continuations
In Theory and Practice of Delimited Continuations,
TPDC 2011.
http://www.cs.indiana.edu/~sabry/research.html
Abstract:
Many mainstream
The ecmascript wiki feed for recent changes
http://wiki.ecmascript.org/feed.php
appears to HTML encode its links, which causes the wiki
to fall back to display pages, rather than diffs. For instance
http://wiki.ecmascript.org/doku.php?id=strawman:strawmanamp;do=diffamp;1303930654
should be
FWIW: I've written down my understanding of the differences
between LexicalEnvironment and VariableEnvironment in ECMA-262:
http://www.2ality.com/2011/04/ecmascript-5-spec-lexicalenvironment.html
Thanks, another surprising detail. The standard disallows
FunctionDeclaration as statement,
Javascript closures bind their free variables by reference;
what does that mean for const functions?
..
var real_f;
const f() { return real_f(); }
I Claus, I'm not sure why this isn't obvious in the current spec. Please
let me know what needs to be modified so that it becomes
- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules
.. Not quite as bad as you wrote.
Sorry, I didn't notice that my attempted summary could be
read as dramatizing the issue!-) The
Hi Dave,
thanks for your reply. I was beginning to fear that these
suggestions had been missed. Let me start directly with
your main point, because it biases the detailed evaluation:
* making nested callbacks better via all of the above
I think this is a deeper problem that can't be solved
Short version:
Javascript closures bind their free variables by reference;
what does that mean for const functions?
Consider extreme cases like this (is this currently permitted?)
var real_f;
const f() { return real_f(); }
This make me wonder what it means for a function to be
Pragmas (ignorable source hints to an implementation) have
become fairly wide-spread in Javascript, but their look and
usage differs widely, and with an increasing number of tools
defining their own pragma conventions, it is only a matter of
time before they start stepping on each others toes.
The idea of ASI seems to be to reduce syntactic clutter, possibly
making programs more readable, which is a laudable goal. But
if the reduction in symbol noise comes at the cost of a rise in
complexity of error-prone interpretation, that actually reduces
readability. And few things frustrate
I'd argue that the things that are wrong with dynamic scope
in the Lisp sense (usage #1) are just as wrong with non-static
scope (usage #2). Dynamic scope in Lisp was anti-modular
because the meaning of a variable could be affected by any
code throughout the arbitrary control flow of the
As an aside: In previous discussions, I've seen these patterns
somewhere (possibly on jsmentors):
( ( obj || {} ).prop1 || {} ).prop2
try { return obj.prop1.prop2; } catch(e) { return undefined; }
The first doesn't handle errors, the second might handle too
many (the second is also a
Dynamic binding is bad, mmmkay? ;)
Seriously, it's not an efficiency thing. Dynamic scope is
easy to write but hard to predict. JS is lexically/statically
scoped almost everywhere, except for with, eval, and
the global object. Strict mode solves with and eval.
Isn't there another culprit
The behavior of References isn't as arbitrary or different from
other languages as it might seem. It's really a way to specify
l-values.
Not arbitrary, but different, and quite drastically so (as far as
usage is concerned). Your remarks helped me to pin down the
difference (and eliminated two
Like most Javascript programmers, I have tended to follow
a simple rule for functions using 'this': eta-expand method
selections, use .bind, or get into trouble.
That is unnecessary, inefficient, and adds clutter.
The problem with rules-of-thumb is that most people only
have two of those;-) I
finding relevant information on the wiki isn't straightforward
for newcomers.
Good point, operators in particular need some navigational
help. I'll do something about it.
Thanks. Btw, other things I've been looking for are timeline,
process, committee information, and software information
Like most Javascript programmers, I have tended to follow
a simple rule for functions using 'this': eta-expand method
selections, use .bind, or get into trouble.
Then I got curious about how method calls determine what
object to pass as 'this': a method is a function selected from
an object,
[since I was lucky enough to be near a good university library
some 15 years ago, and have a long-standing interest in
language design, I'll try to respond to questions from the
other thread here; the hope is to turn those principles from
an obstacle to a tool in Ecmascript design]
As a
I finally got a first look at the 'Virtual Values for Language
Extension' paper referred to in the value proxies strawman [1],
and suddenly find value proxies more interesting.
Somehow the term proxy never suggested to me that this
would allow for user-defined infix operators - perhaps a wiki
In my previous post, I suggested tail nests as a profitable target
for reducing reducing parens and braces that distract from
common code patterns. I made two concrete suggestions, to
make both braces around function bodies and parens around
function applications optional.
The combination of
[this has grown a bit long, because in addition to concrete
suggestions, it discusses the design problems leading up
to these suggestions and includes an extended example;
I hope that makes for an easier read overall, but you
might want to allocate a few minutes to read it in one go]
Summary:
[about protection keys:]
.. I just don't see the general problem (if it is even a problem)
as one that is important enough to try to fix in the language
since it is probably rare and it can be avoided by careful naming.
The problem of variable shadowing happens to be more acute in
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Sorry to astonish you. :)
No problem!-) I was just afraid of the idea being misunderstood
or being associated with fear-inducing phrasing,
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for automatic transformation,
function f() {} // target this binding
(function () {
function f() { // skip this binding
The line directly above introduces two bindings in two scopes. Did
you mean that both of them are skipped, or just one?
This made me feel as if I was missing something, so I went back to the
ES spec:
Further, how would this interact with eval introducing (or in
some systems even removing) lexical bindings?
Disclaimer 1: the Berkling-style systems I'm familiar with did
not support eval, so I cannot argue from experience here
Disclaimer 2: the reason for this was that unlimited
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To
It strikes me as odd to see specific infix operators hardcoded
in the language spec. ..
I'd be interested to learn whether user-defined infix operators
have been considered, to keep the language-level specification
limited but general, while allowing late specification of details
in library
Hi Dave,
Interesting idea; I'd never considered lifting some of these
good syntax ideas from Haskell before.
thanks. Yes, I've often noticed that people equate Haskell
language design with its advanced type system ideas, while
the much more stable ideas (such as reducing syntactic
noise) in
I was looking forward to a Javascript with block scope at last,
but on looking through the proposals, I have some questions:
1. hoisting vs recursive function definitions
Hoisting isn't nice in general, and from the no use before
declaration in [1], it seems that let bindings won't be
A spec workaround would be to stop converting numeric keys to
Strings, ie, 1 and '1' would be different keys. Then number keys
could behave as Array indices, while String keys would behave
as other properties.
Interesting idea, but I think it would be to big of a break from ES5,
ES in general
The little issue I see in returning 1) index properties in ascending
order 2) all other properties in addition order is that there is a bit
of information lost in the process: overall property addition order
(index properties included).
..
Music album in which one title is a number. I lose the
201 - 300 of 302 matches
Mail list logo
