Sorry, I was unclear. I meant 'lambda' for the expression form and 'define' for
the definition form.
Dave
- Original Message -
From: Brendan Eich [EMAIL PROTECTED]
To: David Herman [EMAIL PROTECTED]
Cc: Peter Michaux [EMAIL PROTECTED], es3 x-discuss [EMAIL PROTECTED],
es-discuss
if (h == 0)
h = function() {break};
Did you mean if (x == 0)? That's been confusing me in trying to read your
example.
Dave
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Also, I wonder why lambda in it's block-less form is restricted to
expressions.
I'm with you... but I'd want to check with the experts on the ES grammar to see
whether this introduces any nasty ambiguities.
Dave
___
Es-discuss mailing list
Sounds good to me but it is a little confusing to keep track if let
is either in or out of ES-Harmony and if it is partly in then which
of
the several JavaScript 1.7 uses are in and if there will be let,
let*, letrec semantics.
I've got no crystal ball, but I'd say it'd be unlikely (and
[Removed Mark's address from Cc to stop my stmp server from complaining]
On Jan 18, 2010, at 12:14 PM, Brendan Eich wrote:
Copy and paste. I copy prototype-1.6.0.2.js into mybigfatmodule.js, add my
special sauce which makes good use of Prototype's extensions to primordials
such as
[BTW, I couldn't see what you were replying to. Quoting would be helpful.]
The call-with-current-program-state feature is awfully heavyweight. I suspect
it's plenty useful simply to provide facilities for creating separate contexts
in which modules can be *initiated*, as a way of *kicking off*
We had a good discussion about modules at this week's meeting, and Sam
Tobin-Hochstadt and I have worked out a strawman for a simple module system.
I've posted a first draft to the wiki:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
There are lots of examples to peruse at:
Hi Vassily, thanks for the feedback.
It should be
script type=harmony
// import everything as Math
import Math;
alert(2π = + Math.sum(Math.pi, Math.pi));
/script
This is already possible with the `import Math as Math' form (which
incidentally can easily be compiled to be exactly
Sounds good. A Context is configured with the objects (eg dom, xhr) that the
developer wants to make accessible in the Context. These objects are bound to
an outer lexical frame which all modules imported into the Context can
access. Contexts are the means by which access to platform
But this should be a usable ocap language, not gratuitously lacking any
features from full Harmony that could have been provided safely, merely
because Harmony unnecessarily chose to provide them in an insecurable manner.
That's a bit hyperbolic; no one's proposing an insecurable system. Our
Not quite sure how to unpack the question. Let me try a quick sketch, at least
for the simple modules system:
- a module ID resolver is a mapping from module ID's to module instances
- a module context is a set of module instances
- a module context object is a first-class value representing a
[including the list, which got inadvertently cut]
Yes, I understand that short import is not with, it just smells
like with and like global. Your reasons are correct for language
implementers and I am telling about language users.
To be clear: this is not for implementers, it's for users.
- a module context is a set of module instances
Please call this something else.
Okay.
It is confusing for context to
mean execution context and module context depending on the
context. I've called this a system of modules or sandbox of
modules in the past.
Well, a module system is a
If not, could possibly non-shared state be the default behaviour. And shared
state modules - which share state within contexts - are somehow marked as
shared at module definition. e.g.
module ModShared {
use shared // or some mechanism to signify shared state
...
IMO, this would be
Well, a module system is a language construct that provides modules. I
think sandbox sort of suggests more isolation than is necessarily provided.
PLT Scheme uses the worst possible name for the concept (I won't even say
what it is, it's so awful).
I'll think about alternatives and
Yep. I thought ModuleInstanceGroup was a little over the top. :)
Dave
On Feb 3, 2010, at 3:30 PM, ihab.a...@gmail.com wrote:
On Thu, Feb 4, 2010 at 10:11 AM, David Herman dher...@mozilla.com wrote:
How about module group?
But it's not a group of modules; it's a group of their instances
Well, a module system is a language construct
I not sure I agree with that characterization. A Module is a language
construct as it as specific syntactic element of the language. It is a
specific thing that you have to learn about when you learn the language.
I was pretty imprecise,
I like it. I might prefer module loader for a bit more concreteness. But it
has the benefit of concreteness and familiarity.
Dave
On Feb 3, 2010, at 4:03 PM, Mark Miller wrote:
On Wed, Feb 3, 2010 at 3:11 PM, David Herman dher...@mozilla.com wrote:
Well, a module system is a language
, if I’m being a pain about this but it is pretty clear that everybody
is reading lots of implications into the names that are being thrown around)
Allen
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of David Herman
Sent: Wednesday, February 03
First, this traits proposal looks very nice -- thanks, Tom and Mark, for your
work on this.
I want to add another point about the benefit of new syntax by calling out a
piece of the code.google.com proposal under Performance, where it says: In
order for the partial evaluation scheme to work,
Could macros - or some kind of AOP-ish compile time processing - help:
@addtrait mytrait myobj;
@import acme.mymod; // expands to const acme = {mymod: {myfunc: ...;
Macros wouldn't really solve the I can't parse this problem. You could
package up syntax extensions as macros and provide them
Kris,
Thanks for this proposal. I think it's got a lot going for it. I like the
simplicity of the API, although I think it could be simplified even further.
This is often called continuation passing style (CPS) and is
quite verbose in JavaScript, difficult to debug, and can be very
Hi Kris,
I've been poring over this for a while, and it's still really, really
confusing. Could I ask you to show how you would write the following example
with your proposal?
function setup() {
setFlashing(document.getElementById(notificationArea));
alert(done setup!);
[BTW, your quoted text got garbled.]
In order to utilize leverage continuations with a function that
execute multiple we would need to eliminate single-shot restriction.
You could then create some library function that passed the
continuation to the setInterval function to do something like:
The key idea of this approach is that when a function is called that
contains a yield operator, rather than following a hard-coded
prescription to return an generator/iterator object, this triggers a
call to the startCoroutine variable (from the current lexical scope)
Totally opposed. I don't
Dear all,
We've talked about various let-binding forms in the past, and the
let-declaration form has pretty wide support. The other two forms proposed for
ES4 were more controversial. I've just posted a small strawman proposal for let
expressions that brings this down to just one additional
f(let (a = getArray()) {
if (x.length === 0)
throw empty array;
= a[0]
})
erm, a.length. Like it matters. :)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
Hey all,
I went ahead and wrote a series of blog posts this morning about the way I look
at the design space for single-frame continuations for Harmony. I offer it as
food for thought wrt how to approach the design. Obviously this is my personal
angle, but it also covers a reasonably broad
I think this discussion is getting off-topic. We're happy to have accepted your
initial announcement, but this list is here to discuss the language
standardization and design. Discussions relevant only to a specific
implementation belong elsewhere.
Regards,
Dave
On Apr 8, 2010, at 11:39 PM,
out of the frame, without invoking additional user code first.
Dave
On Apr 12, 2010, at 7:08 PM, Waldemar Horwat wrote:
David Herman wrote:
Thinking about continuations
http://calculist.blogspot.com/2010/04/thinking-about-continuations.html
Your attempted fix for evaluating finally
function foo(...) { f-(...); g-(...); }
[snip]
Of course, and I certainly understand how continuations reify the
frame(s), and how traditional continuations preserve the stack, but I
don't follow how to preserve the stack when you have broken the
continuations apart into separate autonomous
Name sounds like a stripped-down uninterned symbol (http://bit.ly/bY3Jkg) to
me.
Yup.
It's an object with a magic attribute that says, unlike any other object you
might try to use it as a property name, it is not coerced into a string
first. And it is compared by identity when looked
But I meant not only naming convention, but that by this naming
convention this properties (symbols) will be hidden -- just like in
Python, when _ and __ properties become unavailable outside...
You still haven't specified what outside means. What does get to see a hidden
name and what
, 2010, at 9:38 AM, Brendan Eich wrote:
On Apr 16, 2010, at 2:31 PM, David Herman wrote:
PS Still, I have my doubts about using any such mechanisms for versioning.
Incidentally, ROC was just talking about versioning and metadata on the web:
http://weblogs.mozillazine.org/roc/images
One of the semantics I suggested and then dismissed for single-frame
continuations was based directly on the operators shift and reset from the
PL research literature.[1] To my eye, when we dressed them up to look like a
function call (with -), they suggested that we were calling a function in
Also notice that, unlike JS 1.7 yield, a function that uses shift is not
special in that it doesn't immediately suspend its body when you first call
it. But because it's a syntactic operator, it's more manageable for
implementors of high-performance ES engines, since they can trivially
What happens if you don't supply a function but another type, or none?
The simplest thing is to specify it as a runtime error if the argument to shift
is not callable. You're right that there's an overhead to constructing a new
function. But it gives you flexibility that's otherwise a pain for
Hm. Maybe you meant to return the function to allow access to the local
variable
k through a closure? And not a fingerprint
mixed shift(function)
as I read it at first?
I don't know what you're saying, but I have already posted the semantics in
this thread. I *think* it should be pretty
Hello!
I've updated the strawman proposals for static modules and dynamic module
loaders and would love to get feedback from the es-discuss community.
* Static modules:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
I wonder if you considered having an export list, rather than tagging the
individual exports? I think that makes it easier to see/document the public
API of a module. You could at the same time allow renaming on export.
Yes, this is a good point. We chose inline-export for convenience, but
Thought looking at the syntax section it seems that `import Math;` isn't
valid and instead you do it as `module Math = Math`. Why not use import here
as well? My first instinct here is `module` is for defining a module and
`import` is importing it - instead `module` serves a dual function.
a const binding in the module's exports and you'd get an error.
/be
-Charles
On May 16, 2010, at 11:11 AM, Brendan Eich bren...@mozilla.com wrote:
On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
On 15.05.2010 19:22, Brendan Eich wrote:
On May 15, 2010, at 7:53 AM, David
This is a minor point, but rather than all, we'd use * instead, to mirror
import M.* or M.{*} or import * from M; whatever it ends up being.
Agreed.
As for the meaning: from my experience with PLT Scheme it works well for
export *; to export everything that's defined in the module, but not
Along these lines of imports, a regex would allow partial imports.
I'm a little hesitant on this idea; on the one hand it's nice that we already
have literal support for regexps, so it's not a huge conceptual or syntactic
overhead. OTOH, like Brendan suggested for export all except it smacks
See, even after I knew the rules it was too confusing. Can we go back
to using as?
import draw as drawGun from Cowboy;
This is an incomplete suggestion. What do you want the full syntax to be for
multiple imports? Force the user to write a separate one on each line? Bracket
them?
Stupid question - is the following form of (Python-ish) import
possible (from the grammar it doesn't look like it):
[snip]
Or is it the case that with a module {...} declaration the module is
immediately accessible in the scope it was declared in - and no import
required if
) {
if (m.hasOwnProperty(key))
alert(found export: + key);
}
}
inspect(Math);
Dave
On May 16, 2010, at 10:31 PM, Kevin Curtis wrote:
On Mon, May 17, 2010 at 6:02 AM, David Herman dher...@mozilla.com wrote:
This was the point I was explaining here:
https
No worries - the examples page is very useful.
In your original email:
module Even = http://example.com/even.js;;
module Odd = http://example.com/odd.js;;
Is the load keyword missing:
module Even = load http://example.com/even.js;;
Yes, sorry for another inconsistency there. FWIW, I'm
1. Is it possible to import parts of a module to avoid potentially large
network payloads?
Not parts of a module, no. (The semantics of this would be incredibly hairy and
hard to define.) But you can dynamically load modules, so you can write code
that decides dynamically when to load
Coalescing requests (for some value of request) could be pushed down a layer,
not specified as part of the ECMA-262 language. This serves the decoupling
requirement. Is it enough? A while ago Allen wrote about separating
configuration management:
Oh, but you probably meant that the module table form, besides being sugar,
is written in a restricted language that cannot have effects other than to
create module bindings -- cannot do document.write or
document.createElementNS(script) or whatever. In that case we'd want
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
I don't agree with this. Two of us formalized, implemented, and tested
that paper in a month. That is hardly time-consuming, and it's not
very subtle since we have test suites to test our formalization.
I brought up your paper because it's good work. I wasn't criticizing it. But
there's a
You're still not understanding me. My cat could write an executable
implementation of the ES standard library. (Seriously, he's an amazing cat.)
The point is whether you can hit the right level of abstraction, the right
level of presentation, and the right level of specification-- neither over-
You're still not understanding me. My cat could write an executable
implementation of the ES standard library. (Seriously, he's an amazing cat.)
Hm. I was feeling silly at the time but that just came across mean. Sorry about
that. All I meant was that there's more to the spec than just
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
}
}
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
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
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
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
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
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
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() {
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
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
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
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
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
1 - 100 of 654 matches
Mail list logo
