[Disclaimer: I'm not an expert at server code. That said...]
Don't you generally need to manage the policy for these kinds of requests
manually anyway? In particular, you can't actually tell if a user has abandoned
their session, since the browser doesn't let you know when that's happened. So
The way I think about it is, whenever you have X: Y where X and Y are
identifiers, the one on the left is fixed and the one on the right is variable.
- In an object literal, the one on the left is a symbolic property name and the
one on the right is a variable.
- In destructuring, the one on
Why I was asking -- because I saw it in your talk on ES.next, where you used
exactly this approach, i.e. module Foo = http://modules.com/foo.js; --
without any `require`. That's it.
No problem, I didn't mean to chastise. Just trying to keep focussed.
(should I fix my following presentation
Regarding, import M.* via destructuring, it's also arguable whether we
don't need it since it looks like a with.
I don't see any sense in which it looks like a |with|. It's both syntactically
and semantically different. Syntactically, because it's a global (or
module-global) declaration
Hi James,
1) Files as modules do not need module wrapper
Just to confirm, if a JS file contains only a module definition, the
module X{} wrapper is not needed?
That's correct.
2) Set module export value
Is it possible to support setting the
Hi Sean,
Yes, I'm interested in this possibility as well. It'll probably take some
careful working-through of the details to figure out exactly when/where this is
doable, but it's on my radar.
Thanks,
Dave
On Apr 1, 2011, at 7:37 AM, Sean Eagan wrote:
Why not allow the spread operator to
Also, is it currently specified if rest parameters can have default
values?
I'm more skeptical of this one. It's sort of treating empty arrays as falsey,
which they aren't. And I've never noticed a need for this. But that might just
be the BLUB principle in action. Do you have examples/use
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as a
function, it uses the lexical binding of |this|, and if called as a method, it
uses the dynamically pass-in binding of |this|.
Note that the .call
This is what Sam is referring to -- we've been talking about exactly such a
feature. I continue to believe that something like the ^this feature we've been
talking about is as likely to introduce bugs as it is to fix bugs. It's like
special language support for off-by-one errors.
Dave
PS A
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
This is what Sam is referring to -- we've been talking about exactly such a
feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, so that you could
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. :)
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for
The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so
Allen makes the point that class D extends B {...} may look too much like
languages where it means something quite different.
Yeah, I just don't buy the argument that having different semantics should lead
to different syntax: it proves too much. By definition, JS has a different
semantics
Hi Claus,
Interesting idea; I'd never considered lifting some of these good syntax ideas
from Haskell before.
One issue with the Haskell `...` syntax directly is conflict with the
quasi-literals proposal, but we can think about alternatives offline (let's
*not* get into a discussion of
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
Right now, everything that can be expressed via dot notation has an analog in
bracket
Brendan and Irakli both beat me to the punch here -- I would really like to see
stronger evidence that an entire lexical scope is really so onerous.
Everything you say about how Java mitigates the problem is just as applicable
to Harmony.
Java doesn't formalize this, you're right — but if I'm
Hoisting isn't nice in general, and from the no use beforedeclaration
in [1], it seems that let bindings won't be hoisted,
not even to their enclosing block.
That page is not yet complete. There's plenty more work to do on it, but we
probably won't be able to find much time to do
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach to
specifying weak maps. I don't think we should be putting GC algorithms in the
spec at all; that would be overspecification. Instead, we should just focus on
defining reachability, and leave implementors free to
measurements.
(They'd be especially hard to automate, but I'd rather have the ability to test
manually than none at all.)
Anyone have experience with this from, say, the JVM and its weak references?
Dave
On Mar 20, 2011, at 8:20 AM, David Herman wrote:
It's weird, though--specifying anything
I said that WHATWG has done some on work specifying what currently
happens in browser (joining with your idea of be[ing] compatible with
existing event queue semantics). One idea would be to see what they've
done, get inspired and specify the event queue in ECMAScript.
OK. I'm on board for
for a
lower constant overhead in the typical case), we should clearly leave to
implementors. There is indeed nothing normative about this.
On Sun, Mar 20, 2011 at 7:20 AM, David Herman dher...@mozilla.com wrote:
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to me.
This gets at my other objection. Code is far harder to debug when every
single property lookup
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists. Another part is
introducing new concepts and features to the language (like promises and vats).
I want to hear what Mark has to say at the TC39 meeting, but my
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists.
Is this already done in the current proposal? Because I haven't found it.
Sorry, I guess I should say, we can't add concurrency without having it be
P.S.:
A small change, e.g. can be to make next as a getter since it doesn't accept
arguments.
g.next; // 1
g.next; // 2
But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterator. A
getter interface obscures
Hi David,
We have a strawman for making the enumeration order well-specified:
http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
Would that not be sufficient for the defineProperties case? I'd prefer that to
adding another trap.
Dave
On Mar 12, 2011, at 1:15 PM, David Bruant
But I miss the linear algebra library to go with it.
Can you send references to example libraries for other systems that you would
like to see?
Especially for the binary data approach, as it's removing an order
that might be implicitly known - sorry, I don't know how to express that
better,
A big favourite of mine (I'm biased, though...) is the Eigen2 library
(LGPL3+):
I can't speak for other browser vendors, but I think that license isn't
compatible with Mozilla's codebase. But thanks for the reference.
Using the small, fixed size subset of that lib and exporting the
On Mar 3, 2011, at 5:33 PM, Waldemar Horwat wrote:
If we're saying that Harmony is strict-only, settable by a script tag, what
will indirect eval and the Function constructor do if the evaluated code
doesn't start with a use strict directive?
Yeah, strict-only is probably not quite the
So I think it might be a little misleading to say Harmony is strict-only.
Who ever said that? :-P
Yikes... not playing who-said-what. For whatever reason, Waldemar got the
impression that someone said it, and I'm correcting the misconception, that's
all.
I've written that Harmony is based
Hi Jeff,
I agree that the spec should deal with multiple global objects. I'm aware of a
few of the subtleties of multiple globals, but I wouldn't be surprised if there
are more. Thanks for raising this one. I created a placeholder strawman last
week, because I've been intending to get into
I've been working on a prototype implementation of the binary data spec in pure
JS (implemented via typed arrays) and I've been bitten by the lack of a
standard mechanism for subclassing Function.
I'm using proxies for the implementation, and Proxy.createFunction doesn't let
me specify a
PS Correction: it's actually a non-standard extension that regexps are callable
in SpiderMonkey. So the invariant is that the only callable non-host objects
are descendants of Function, or possibly host objects. This doesn't change my
overall point, though.
On Feb 23, 2011, at 2:26 PM, David
With your optional argument, I see a second solution that could be
consistent. The prototype chain could contain the provided prototype
then Function.prototype (obj -- proto -- Function.prototype --
null as opposed to your proposition which is: obj -- proto -- null
). Hence, there would be
Too much and too complex, say I! ;)
I liked your previous thinking that we should just return a fresh array. And in
the interest of keeping it dead simple, let's just fix it at 32 bits -- always.
Then the question is: string, array, typed array, or binary data?
I say: let's make it typed array
On Jan 27, 2011, at 8:38 AM, Wes Garland wrote:
Kris Kowal's query is interesting: is lazy evaluation worth considering for
Simple Modules?
module M {
export var foo = 42;
export function bar() { return foo; }
alert(hello, world);
}
In the example above,
On the opposite side of the argument, I presume that this means that
modules are evaluated when their transitive dependencies are loaded.
This would imply that the order in which the modules are delivered,
possibly over a network using multiple connections, would determine
the execution
Kowal wrote:
On Thu, Jan 27, 2011 at 9:14 AM, David Herman dher...@mozilla.com wrote:
…but it is required to evaluate them in their declared order,
deterministically.
Would you explain how declaration order is inferred from the contents
of the unordered of files?
It's clear
You can use module loaders to do exactly this (I believe, based on my
understanding of CommonJS). It would look like:
var ml = ... the desired module loader ...
var a;
if (someCondition) {
a = ml.load(a1);
} else {
a = ml.load(a2);
}
Correction: you have to use callbacks for dynamic
On Jan 26, 2011, at 4:04 PM, Brendan Eich wrote:
On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is
an exported object?
Sam addressed that directly (nothing is statically known), cited in full
below.
Oh, I
We have previously discussed adding standard handlers to the specification,
i.e. an NoopHandler and a ForwardingHandler.
Yes, and Tom and Mark have been working on this and making good progress. They
have a forwarding handler mostly worked out, which we discussed yesterday at
the
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up that
implements just the other traps you want to implement, and let the others fail
soft.
Dave
___
es-discuss mailing list
Sure. This is the use noasi or use semicolons idea.
Or just no asi. /bikeshed
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Hi John,
Module declarations are only allowed at the top level of a script or module,
but for convenience, they can nest within top-level blocks, and are hoisted
to be in scope for the entire containing script or module.
Can someone explain what this sentence means?
To me it says:
We would probably make it a contextual keyword so you could still use it in
non-expression contexts (e.g., to the right of '.' and left of ':' in object
literals), but unless we played some clever tricks, which I'm not sure would be
worth it, using it as an identifier would be a syntax error.
There's some flexibility built in to the system via module loaders. The
filesystem modules example is hypothetical; it assumes a built-in module
loader that maps files available on the filesystem to corresponding
pre-defined, nested modules.
On the web, you would do almost as you suggest:
//
this one
But will the runtime know how to correctly resolve the (module b = b.js;)
that comes from a.js? Or will that declaration have to be rewritten?
On Tue, Dec 28, 2010 at 1:30 PM, David Herman dher...@mozilla.com wrote:
There's some flexibility built in to the system via module
Dave, under the spec for Operation OwnProperties(obj) step 1, you don't
explicitly state that these index properties are to be enumerated in numeric
order. An oversight?
Oops, yes, thanks for catching that. I've updated the wiki.
Also, you misstate that indexes are properties with values
You've said this apples to oranges thing many times. I just don't get it.
My comparisons at
http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields show
that these two semantics address extremely overlapping use cases. For both to
be in the language, with one group (including
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty serious misunderstanding of the private names
proposal. In every variant of the proposal, the object
On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty
On Dec 21, 2010, at 10:41 PM, David-Sarah Hopwood wrote:
Again you seem to be confusing the inherited soft fields proposal with
the *separate* proposal on desugaring the private name syntax to inherited
soft fields.
I think I may have been misunderstanding what Mark was actually
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case that
Oliver raised
I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming
Hi David,
First of all, I think you may not be reading the current private names
proposal. Allen wanted to change the name so he created a new page:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names
Part of what you're reacting against is in fact what he changed (more below).
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow identify which
classes (in the prototype chain for protected) have access to the object?
I'll leave the somehow up in the air, but you could introduce a [[Private]]
attribute
I never said I don't want syntactic support. I said I don't like the syntax
you proposed. You and Dave have now both said that you consider this to be
the main issue.
Hm, I certainly didn't intend to say that. I'm not quite sure what you're
referring to that I said. I don't necessarily have
at 5:24 PM, David Herman dher...@mozilla.com wrote:
Ok, I open it for discussion. Given soft fields, why do we need private
names?
I believe that the syntax is a big part of the private names proposal. It's
key to the usability: in my view, the proposal adds 1) a new abstraction
This sounds great, but doesn't this kind of violate referential
transparency?
That's a loaded criticism. JS doesn't have referential transparency in any
meaningful sense. But it does generalize the meaning of the dot-operator to be
sensitive to scoping operators, that's true.
Couldn't the
Without new syntax, isn't soft fields just a library on top of weak maps?
Dave
On Dec 16, 2010, at 3:47 PM, Mark S. Miller wrote:
On Thu, Dec 16, 2010 at 3:23 PM, Brendan Eich bren...@mozilla.com wrote:
On Dec 16, 2010, at 2:19 PM, Mark S. Miller wrote:
Currently is JS, x['foo'] and
I'll address this last point first, since this seems to be the core issue.
The question I am raising is: given soft fields, why do we need private names?
I didn't see that asked as a question; I saw it asserted, but not opened for
discussion.
And I disagree. Now, I happen to think it's not
I pretty much abandoned that line of investigation with the conclusion that
generators:
http://wiki.ecmascript.org/doku.php?id=strawman:generators
are a good (and well-tested, in Python and SpiderMonkey) design for
single-frame continuations. They hang together well; in particular, they
);
}
... foo.responseText ... bar.responseText ... baz.responseText ...
});
I should also point out that the core of jstask is 7 lines of code. :)
Dave
On Dec 9, 2010, at 7:55 AM, David Herman wrote:
I pretty much abandoned that line of investigation with the conclusion that
generators:
http
Allen suggested something like this in the September meeting. One issue people
had with it was that it adds another violation of the equivalence between a
statement stmt and (function()stmt)(), which is a refactoring hazard. Put
differently, if you have some code with static declarations in it,
Can you give a small example (it's just interesting) -- to see the issue?
Sure thing. Say you're writing some code with a constant value, and somewhere
inside the code you use `static':
var METERS_PER_SQUARE_KILOJOULE = 17.4;
...
static foo = 1;
...
f(foo,
if you had said:
const foo=1;
In both cases, wrapping the declaration with a function changes its scope??
Allen
-Original Message- From: David Herman
Sent: Tuesday, November 23, 2010 9:24 AM
To: Dmitry A. Soshnikov
Cc: es-discuss@mozilla.org
Subject: Re: `static` keyword from C/C
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
What are keys, values, and properties here? Global functions?
Those are API's suggested in the strawman:iterators proposal. They would be
importable from a standard module.
How would a new object
How would a new object abstraction T customize them just for instances of T?
By writing its own custom iteration protocol via proxies with the iterate()
trap implemented appropriately. E.g.:
function MyCollection() { }
MyCollection.prototype = {
iterator: function() {
1a) New semantics should use new syntax in a manner that clearly avoids
confusion with existing syntax.
1b) Syntax should generally be suggestive of a reasonable interpretation of
the semantic
1c) Harmony is not being designed using the no new syntax rule
1d) There is nothing sacred
2a) If existing syntax is given new semantics, it should extend the existing
semantics conservatively. Otherwise, the new semantics should get new syntax.
Perhaps I should have numbered that 1a'). :)
Dave
___
es-discuss mailing list
I somehow suspect stringifying the iterator next() return value from for-in
machinery will not placate folks who want for-in not to be metaprogrammable.
Nor would it work -- you wouldn't be able to get the values() or properties()
iteration behavior, for example. It would be the worst of all
And (sorry, I'll try to keep replies in one message next time) for vs.
forvals does not exactly scream keys vs. values, since for is only
about keys if you know ECMA-262 and expect the mystery meat of enumeration.
IMO, forvals is a non-starter, as is foreach or for each. The for part
of the
If harmony would introduce this syntax guarded under a new script type,
there
would at least be no danger of breaking the web (existing scripts).
That sounds like an interop nightmare -- you're talking about forking the Array
type between language versions. Keep in mind that non-Harmony and
How 'bout extending proxies to provide an introspection API?
That's a really vague question. It would help to say what kind of introspection
you had in mind.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
Are you suggesting a) that struct types should always be value types, or b)
some sort of extension to the binary data spec that allows the creation of
immutable structs that are value types?
I'm afraid a) just seems unworkable -- compound binary data needs to be
mutable, and its sub-components
Given script type=harmony as an opt-in, I'm puzzled about how it would
work anyway. Since it is per script, not per frame, presumably
script type=harmonyuse strict; var e1 = eval;/script
scriptuse strict; var e2 = eval;/script
script ...use strict; e1 === e2 /*results in true*/ /script
ES3 `catch' is block-scoped. At the last face-to-face, we talked about
statically disallowing var-declarations from hoisting past let-declarations:
function f() {
{
let x = inner;
{
var x = outer; // error: redeclaration
}
}
Waldemar, thanks for the great notes. One quick comment on the binary data
notes:
int64's: Open issue. Reference semantics are annoying, but what's a
realistic alternative?
int128's? Those come up increasingly often in SSE programming.
We briefly discussed bignums as a realistic
I've recently updated and clarified the draft strawman for simple modules:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
One of the key changes is to the initial environment of modules, addressing the
issue of module name capture pointed out a while back by Jasvir Nagra and
Yes, that's an accurate summary. It also brings me back to Dave's earlier
question about the limited choices provided by the Traits library.
...
Long story short: it's definitely possible for a Traits library to offer more
knobs, although I'm not sure whether the increased complexity is
Also, the duality of Object.create vs Traits.create accommodates traditional
vs high integrity quite well -- without AFAICT compromising either.
It creates a false choice, though (all or nothing). IIUC, with Object.create,
you don't even get the conflict checking. And then you've really lost
But since Traits seems to be blocked from advancing,
Is there someplace I should read to understand why Traits cannot advance?
I asked MarkM off-list what the reason was, and he replied that there
was an objection (raised by Waldemar?) to how class evolution was
handled.
My feeling, and
Does that feeling carry over to any variants that might actually
include new syntax?
The issue isn't whether it introduces new syntax, it's whether it introduces
new semantics. The Traits library, as written, is completely implementable as a
library in the existing language.
That's not to
libraries should generally be very widely used and very stable before they
are added to the ES standard library.
That would seem like an unfair penalty. Am I to infer classes-as-sugar OS
preferred because it _can't_ be implemented as a library (despite being a
more experimental approach,
Agreed; perhaps my question was not clear. If there was a Traits-like
proposal that did include new syntax, would you be against it because
you can implement something similar as a library without needing new
semantics, or would you be more inclined to reserve judgement until
you could
But HashMaps and WeakMaps both map objects to values. The difference is just
that, with WeakMaps, the mapping is weak. The name is excellent, short, and
clear.
Perhaps ObjectMap would be better?
That wouldn't distinguish them from HashMaps, since they are both object maps.
WeakMap is a
That page currently has TBD semantics.
Yeah, that's part of the work that needs to be done. Intuitively, it's a simple
idea: ToName essentially generalizes the current semantics of property lookup;
instead of trying to convert the property to a string, you try to convert it to
a
Mark's restricted production for CallExpression attacks the hazard even more
directly, but apart from our aversion to restricted productions, what might
it break?
I don't see offhand what it might break. This question seems easy to
investigate empirically-- crawl the web looking for
Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap?
+1
I 3 WeakMap.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It would be
good for this to be expressed in one of the examples, and
for it to be clarified in the description of semantics that
every script is also an anonymous module from which the
exports are only accessible through the lexical scope
shadowing (I assume) and by being bound to a module
Hi Kris,
Thanks for your thoughts; I'll keep reading but I do want to respond to a
couple points that I don't think are quite accurate.
The one step forward comes from handling cyclic dependencies
elegantly. If I am correct, this is the feature we gain from second
classness and from not
Sorry for the slow reply -- was sick
No worries-- hope you're feeling better.
Years of PL research and experience have demonstrated that explicit linking
tends to be unwieldy and inconvenient.
That needs to be added to my reading list. Cite away! :)
ML is dead; what more evidence do
I don't have the time or inclination to provide a full bibliography.
I consider your argument withdrawn, then.
Excuse me? My argument is not withdrawn (are we in court?). If you are
unaware of decades of prior art on modules, that's not my failing but yours.
My argument was and remains that
zero.js:
module One = load 'one.js';
module Drawing = load 'gun.js';
module JQ = load 'jquery.js';
one.js:
import JQ;
module Two = load 'two.js';
two.js:
import JQ;
import Drawing;
Drawing.draw();
The module of concern to us is one.js. According to your proposal, one.js is
I'd just like to express my enthusiasm for taking a formal approach to the
kernel language. For everything outside the kernel, defining it by
self-hosting, by a meta-circular interpreter (where the interpreter is
written only in the kernel subset of the language) or by desugaring is fine.
Hi Mike, sorry I overlooked this message.
| This allows cyclic dependencies between any two modules
| in a single scope
1) Is this to say that cycles are allowed, or not allowed, in
other scenarios? (f ex remote or filesystem-loaded modules)
It's an automatic consequence of lexical
Heh-- excuse my bogus BNF! That's just a made-up extension that allows 1 or
more instances of MRL, separated by the ',' token. Spelled out:
MRL+(',') ::= MRL
| MRL+(',') ',' MRL
PS If this is still unclear, just replace MRL+(',') with MRLList, and add the
production:
That's surprising. Within a moduleloader I would have thought that
same url meant the same static module. Across moduleloaders maybe not.
The problem is defining same url. One option is that same means identical
string but then when http://example.com/foo.html says:
script
module A =
Arjun Guha, Claudio Saftoiu and Shriram Krishnamurthi have a recent paper on
the topic:
http://www.cs.brown.edu/~sk/Publications/Papers/Published/gsk-essence-javascript/
Having had some experience with this question myself, let me just say that
while formalization is appealing, it's a
So both the moda.js and modb.js source files can contain (for example):
ModUtils.myfunc();
And can import the exports of ModUtils:
import ModUtils.myfunc;
myfunc();
Yes.
Is it correct that a module declaration within a script tag only has
scope within that script tag?
No, each script
501 - 600 of 654 matches
Mail list logo
