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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
[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:
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!);
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
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
[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
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
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
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:
[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*
[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
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
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
601 - 654 of 654 matches
Mail list logo
