On Oct 2, 2014, at 8:31 AM, Andreas Rossberg rossb...@google.com wrote:
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static unresolvablse
reference rejection to be part of the module semantics. But we've never
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote:
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote:
I just realized this has an unfortunate implication for REPLs. Suppose
you make this typo:
js let x = Math.cso(a)// oops, TypeError,
On Aug 28, 2014, at 10:10 AM, Ian Hickson i...@hixie.ch wrote:
Here are the changes that would be needed to make the ES6 loader
infrastructure underpin the Web platform's loader infrastructure
(basically, placing the ES6 loader the management layer between the Web
platform APIs on top, and
On Aug 11, 2014, at 5:06 PM, Ian Hickson i...@hixie.ch wrote:
So I'm trying to figure out how to spec the HTML spec's Loader.
We should coordinate -- I've been actively working on this (not the spec per
se, but the design) with people engaged in the JS modules work. The HTML
default loader
On Aug 12, 2014, at 2:05 PM, Ian Hickson i...@hixie.ch wrote:
Assume my script is http://example.com/test.js, and assume that there is
no extra information (nobody has registered any module names or anything
like that). If I do:
import a;
import ./a;
import /a;
import
On Aug 12, 2014, at 2:46 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 12 Aug 2014, David Herman wrote:
This is part of the design work we're actively working on. I'd ask you
to hold off until we have some more information for you. I'll keep you
posted -- we should have some more details
Thanks to everyone for working through the issues around ModuleImport. I know
it's been frustrating, but the discussions have really helped clarify the key
constraints.
## Constraints
First, let me restate the most important arguments. In favor of removal:
* **The syntactic distinction
On Jun 19, 2014, at 2:03 AM, Axel Rauschmayer a...@rauschma.de wrote:
Does the proposed syntax clash with `export * FromClause` (which, I’m
assuming, re-exports everything, not just the named exports)?
No inconsistency; it imports everything. Exactly the same semantics as always,
just a
On Jun 19, 2014, at 3:31 AM, Michał Gołębiowski m.go...@gmail.com wrote:
Thanks, Dave, for bringing that up, it shows you're open for feedback. That
said (bikeshed begins),
lol :)
what's wrong with:
```js
import fs as fs;
```
Indeed we've talked about that one before. Some objected to
Your proposal is appealing but I haven't convinced myself it works. There are a
couple bits I haven't quite grokked.
The special `constructor` method in ClassDeclaration/ClassExpression syntax
would desugar to a static @@new method. This class:
class Point {
constructor(x = 0, y
This was brought up on specifiction:
http://discourse.specifiction.org/t/navigator-timezone/152
Does anyone know why it was left out of the first version of the Intl API? Just
for lack of time? Is it planned for the next edition? Are there tricky issues
around standardizing IANA time
On Jun 17, 2014, at 5:31 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Interesting questions in that thread about what to do about time zone
changes. An event for time zone changes seems important, but we don't
currently have any precedent for standard library events in
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
I'm a bit grumpy that this is being brought up again, and
this late, and in multiple forums, but as it seems that people want to
talk about it again, that talking about it again is the thing to do...
Sorry about that. :( But the
On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Nope, it's always been designed this, going back to the original wiki
strawman
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I
assume the original FF implementation.
It has also
On Apr 29, 2014, at 12:17 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Anyway, regardless of the specifics of my `using` proposal, I hope that
highlighting the iterability vs. disposability aspects of this conversation
was helpful to people.
I do think it's helpful for
On Apr 25, 2014, at 9:10 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
People will write code like this if we allow it. But we don't have to allow.
We can preserve the semantics of try-finally by simply making the occurrence
of the 'yield' operator syntactically illegal within the try
On Mar 14, 2014, at 9:27 AM, John Barton johnjbar...@google.com wrote:
I've used es6 modules for several months now and I'm curious to know when I
would want to leverage mutable bindings.
So cycles work!
// model.js
import View from view;
export default class Model {
...
On Mar 14, 2014, at 9:37 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I like that more I read about this, more the `with` statement comes into my
mind ...
There's nothing like this in JS today, so if you're only looking for precedent
there, you're only going to be able to come
On Mar 14, 2014, at 10:50 AM, Russell Leggett russell.legg...@gmail.com wrote:
I completely agree with this. It looks like a modifier.
This is a good point, and folks working on the Square transpiler noticed this,
too. I think there's a more surgical fix, though (and I'm not entertaining
Sad panda. At least we can disable it in strict mode, right?
And who knows, maybe some day, some day...
Dave, dreaming of ES24
On Mar 13, 2014, at 4:59 PM, Oliver Hunt oli...@apple.com wrote:
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've
I think it should be Module.isModule.
Dave
On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
it's not going to be instanceof for various technical reasons.
I suspect, we can have a isModule predicate function somewhere. Perhaps,
Reflect.isModule or
OK, we can discuss and report back. We'll definitely want to take into account
Guy's use case about being able to recognize module instance objects as such.
Dave
On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 21, 2014, at 12:08 PM, David Herman wrote
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote:
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
Rumors is a bit much. :) The notes do show the discussion but the resolution
for some reason didn't get recorded. IIRC
On Feb 7, 2014, at 8:06 AM, John Barton johnjbar...@google.com wrote:
The first goal listed for ecmascript modules:
• Obviate need for globals
(http://wiki.ecmascript.org/doku.php?id=harmony:modules).
Ironically, the current proposal for module loading includes a global
System and
On Feb 10, 2014, at 8:55 AM, John Barton johnjbar...@google.com wrote:
Indeed, however, this herring is only red on one fin: the mutability of
System is not limited to the registry and in fact every aspect of the System
is mutable. As far as I can tell, a mutation to say normalize or locate
I'd like to suggest another sense in which you may have gone down a bad path:
you're assuming that await is paired with function*, but it could instead be
(like C#) paired with its own async-function syntactic form. Let's say for the
sake of argument that async is just a keyword that takes a
On Jan 27, 2014, at 10:58 AM, David Bruant bruan...@gmail.com wrote:
Agreed. Note that I didn't suggest to stop writing inline scripts and
proposed an alternative to script@module that can work today.
Granted, it's somewhat hacky, but I think it can work during the period
during which
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code. It also
allows you to
[Resending, not sure why it's not getting through to the list...]
On Jan 27, 2014, at 10:41 AM, David Herman dher...@mozilla.com wrote:
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write
Here are several ways to think about return:
- A generator function is like a normal function but it can be paused. The act
of pausing can send an intermediate value out to the caller (yield's argument)
and the caller can send an intermediate value back in when resuming (yield's
result). None
On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:
So then there would be two versions of the same module, and a module could
get access to both these modules at the same time. For example, if ModuleB,
which depends on ModuleA is loaded and linked, and later ModuleA is
On Jan 23, 2014, at 4:49 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
Task.js is still on JavaScript1.8, and is not ES6-compatible. It won't
work with modern browsers, or with Regenerator.
Fork and fix, should be easy. I expect a PR would be accepted in due course.
On Jan 6, 2014, at 8:10 AM, Brendan Eich bren...@mozilla.com wrote:
To further constrain design (since design is mostly about leaving things
out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let
blocks and let expressions, which came up recently. We should not revive
On Nov 28, 2013, at 12:25 AM, Axel Rauschmayer a...@rauschma.de wrote:
Source: David Herman,
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md
Can someone elaborate? I don’t see an alternative.
I can't remember the example I used in the meeting, but one example
On Dec 9, 2013, at 12:36 PM, Axel Rauschmayer a...@rauschma.de wrote:
What I’m worried about is conceptual simplicity. I like function declarations
and prefer them to function expressions, but recently did a small survey on
Twitter and was surprised to find out that the majority of people
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Nov 17, 2013, at 6:14 , David Herman dher...@mozilla.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of the
reasons why script async was a non-starter
On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote:
Could someone help me understand why two goals for parsing JS is a good thing?
Hm, it sounds like you've assumed a conclusion already. Let me try to explain
anyway.
Scripts are for synchronous loading and evaluation;
On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote:
Does this imply module src= ?
Works either way, inline or external. (Requiring src= is one of the reasons
why script async was a non-starter.)
Dave
___
es-discuss mailing list
IOW expose the first-class reference type of ECMA-262 via a standard library?
Just say no! :)
First, the module function API is written up wrong on the wiki; the function
won't take any arguments at all. My apologies, I discovered my mistake as I was
working on the spec writeup in the last few
On Oct 25, 2013, at 7:49 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It turns out that even in pseudo code, this is a fairly complicated set of
runtime validation rules to apply. I'm having a hard time convincing myself
that the runtime computational and meta data costs of this
On Oct 31, 2013, at 7:10 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
I see that Jason added a Loader.prototype.define to his reference
implementation.
https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177.
This is great. It is a much needed capability to allow
On Nov 1, 2013, at 7:44 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
Now... good use cases could be a sufficient counterargument to all
this. Maybe we should add `import * from` in 2014. I just want to make
it totally clear why it's designed this way for ES6. `import * from`
poses
On Nov 1, 2013, at 6:19 PM, David Herman dher...@mozilla.com wrote:
On Nov 1, 2013, at 7:44 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
Now... good use cases could be a sufficient counterargument to all
this. Maybe we should add `import * from` in 2014. I just want to make
On Oct 31, 2013, at 8:06 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
Make sense but I'm not sure it is needed/desired.
I agree, actually, despite being the one who put it in there in the first
place. I originally intended it as a convenience e.g. for quick scripts. But by
itself it's
On Oct 30, 2013, at 1:56 PM, Luke Wagner l...@mozilla.com wrote:
Just to be sure, do you agree that both the {lo, hi}-returning API and the
magic-property API should both be able to achieve equivalent performance on a
JS engine that has specifically added and optimized these int64 builtins?
On Sep 27, 2013, at 9:07 AM, David Bruant bruan...@gmail.com wrote:
I agree with the intent of keeping semantics of inter-worker and
inter-machine very close, but the difference in terms makes very clear that
not being able to differenciate the 2 cases incurs an information loss that
can
On Sep 27, 2013, at 8:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
What's the use case for Symbol.keyFor?
The use case was actually suggested in a response to dherman earlier in this
thread when he mentioned sharing symbols
On Sep 27, 2013, at 10:02 AM, David Herman dher...@mozilla.com wrote:
- don't share symbols between workers
Follow-up thought: it seems there are actually two concepts that both get
grouped under realms and yet might warrant distinction. These correspond on
the web to two same-origin windows
On Sep 27, 2013, at 10:14 AM, David Herman dher...@mozilla.com wrote:
On Sep 27, 2013, at 10:02 AM, David Herman dher...@mozilla.com wrote:
- don't share symbols between workers
Follow-up thought: it seems there are actually two concepts that both get
grouped under realms and yet might
On Sep 27, 2013, at 12:05 PM, David Herman dher...@mozilla.com wrote:
export const serialize = m ? m.serialize : new Symbol(friendly name);
And... of course I meant `Symbol()` rather than `new Symbol()`. Haven't
retrained my muscle memory from the days of the object-based API. ;)
Dave
On Sep 26, 2013, at 1:10 PM, François REMY francois.remy@outlook.com
wrote:
TLDR == The web needs a way to express executable code that does not rely
on its parent context, is guaranteed to be side-effect-free, and can be
executed safely anywhere (even in a different
On Sep 26, 2013, at 3:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Maybe the exception could be enumerability exception could be concise methods
with string literal property names that do not parse as IdentifierName.
http://www.youtube.com/watch?v=VX4DJUr5oYg
Dave
On Sep 26, 2013, at 3:48 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
I don't understand why this is happening. There was fairly strong consensus
on symbols at the last meeting, and nothing new has been brought to the
table. Why are people's opinions suddenly changing? Vague
On Sep 26, 2013, at 3:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Oh, that's not Hungarian notation, it's just a name space qualifier.
Don't talk down -- Rick was making a metaphor.
But, if you assume that we will added a real private state mechanism into ES
6.1 or ES6.2 will
So let's assume there is such a registry. You can avoid accidental collisions
with the ugliest name in the universe -- gensym that thing to the n'th degree
-- but you're no longer forcing all clients to deal with the ugliness. You've
abstracted it behind your library. Let's say I'm implementing
On Sep 26, 2013, at 4:26 PM, Rick Waldron waldron.r...@gmail.com wrote:
Thinking about this in terms of tooling, at even the terminal level, might
look like this: http://gyazo.com/f61d0e25366ce7e526c79ab7fa77cb17.png
No no, the GUID doesn't go in user land objects. It only goes in the
On Sep 26, 2013, at 4:22 PM, Mark S. Miller erig...@google.com wrote:
I am saying collision is an issue, but that it only seems that Symbols solve
it because we haven't yet designed the registry. So we should do so first,
and then re-examine this question in the context of a concrete
On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I meant, if you didn't have symbols you could pretty much do the same thing
by exporting a name that is bound to the GUID string as its value. That
exported name could be imported by clients and used as the friendly
On Sep 26, 2013, at 7:01 PM, Kevin Smith zenpars...@gmail.com wrote:
- Enumerability? Yawn... Enumerability of user-created meta-level method
names is fine and should be expected, just as we expect enumerability of
_-prefixed method names today.
Whether you personally use it, for-in is a
Axel wrote:
The problem is that you have to bite the bullet of syntactic inconvenience
for either default imports or normal imports.
Correct. This is the #1 justification.
Rick wrote:
Subjectively, this is really hard to read, versus the curlies which provide a
visual boundary (also
On Sep 8, 2013, at 12:45 PM, Brendan Eich bren...@mozilla.com wrote:
Erik Arvidsson wrote:
Oh, I forgot about that wart.
Are default imports a wart no matter the syntax, or only because of this
brace imposition issue you've identified? If the latter, perhaps there is
another solution
On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I think the right-way to think about structs is as an record structure with
no properties fixed behavior provided by a wrapper. Very similar to the ES
primitives except that structs can be mutable. The way to
On Aug 30, 2013, at 12:46 PM, Filip Pizlo fpi...@apple.com wrote:
OK - by sanepants do you mean that there is no weirdo aliasing? Going back
to my example of field 'a' aliasing field 'b' - is it possible?
There is plenty of aliasing possible, but I'm trying to understand what you
mean
On Aug 30, 2013, at 3:46 PM, David Herman dher...@mozilla.com wrote:
E.g., if I have a struct type
var T = new StructType({ a: t1, b: t2, ... });
then for any given instance x of T, I know for sure that x.a and x.b do not
alias the same storage.
(Except, of course, if t1 and t2
On Aug 30, 2013, at 3:54 PM, Filip Pizlo fpi...@apple.com wrote:
Yup, that's what I was concerned about. And reading over the spec I agree.
But just for sanity, we're guaranteeing this because you cannot create a
struct type instance by pointing into an arbitrary offset of a buffer - you
On Aug 30, 2013, at 4:20 PM, Filip Pizlo fpi...@apple.com wrote:
This is the kind of weirdness that I hope struct types *don't* have, if their
alleged purpose is to help people optimize their code.
This is a great point, thanks. On the one hand, I concluded long ago the
exposure of the
On Aug 27, 2013, at 9:47 AM, Filip Pizlo fpi...@apple.com wrote:
I do. Placing named properties on arrays makes sense. Consider a matrix
implemented as a Float32Array, with named properties telling you the numRows
and numCols. Just one example.
There are of course other ways to achieve
not
suitable for a lightweight migration to structure like logic)
Thanks.
On Tue, Aug 20, 2013 at 4:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Awesome, thanks!
On Tue, Aug 20, 2013 at 4:12 PM, David Herman dher...@mozilla.com wrote:
On Aug 20, 2013, at 1:31 PM
, Aug 20, 2013 at 4:12 PM, David Herman dher...@mozilla.com wrote:
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
[In this
page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects), and in
the latest meeting note too, I can read both uint8
If necessary, i.e. if people want to release it before modules, we can make it
available in a single top-level object, but I would not at all favor dumping
everything onto the global scope.
Dave
On Aug 21, 2013, at 12:07 PM, David Herman dher...@mozilla.com wrote:
The intention has always
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote:
I really hope that uint64 from value type spec and uint64 from typed object
spec are one and same thing (we now in typed objects spec allow using
uint8/uint16/.. co to be used as conversion functions).
Agreed, and my
On Aug 21, 2013, at 2:36 PM, Brendan Eich bren...@mozilla.com wrote:
David Herman wrote:
Any, String and Object should still be uppercase. The naming convention is:
value types lowercase, reference types uppercase.
Is String really a reference type? Currently you can't tell, and JS docs
In Lisp it makes sense to allow binding keywords because there's no such thing
as a keyword: once you bind it, it's a variable and you can refer to it. In JS
it's impossible to refer to it as a variable so it's just an (un)attractive
nuisance.
The only place where I could see this being
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
[In this page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects),
and in the latest meeting note too, I can read both uint8 and Uint8, as
example.
Bug. Fixed, thanks.
**The Question**
How is
On Aug 14, 2013, at 9:54 AM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
throws
to bind to undefined you would say:
var {p=undefined} = {};
OK, so it's turned out to be refutable nevertheless.
This is *not* what I remember of the conversation, at all.
My understanding was
On Aug 15, 2013, at 9:27 PM, David Herman dher...@mozilla.com wrote:
we couldn't really come to any conclusions without Brendan and Andreas there
My mistake, Brendan was there. It was only Andreas who wasn't there.
Dave
___
es-discuss mailing list
On Aug 8, 2013, at 7:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 8, 2013 at 3:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
To me the answer always seemed obvious: use the slow-script dialog. What am
I missing?
That seems like a bad answer. Slow-script
On Aug 8, 2013, at 2:08 PM, K. Gadd k...@luminance.org wrote:
Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual Basic/Windows
Forms and pumping the message loop in a normal C application. That is, you
can
On Aug 4, 2013, at 8:01 AM, Axel Rauschmayer a...@rauschma.de wrote:
My guess: if you re-export something from a module, then you still have to
import it if you want to use it in that module. Is that correct?
Correct.
Examples of re-exporting:
export * from crypto;
On Aug 12, 2013, at 5:40 PM, François REMY francois.remy@outlook.com
wrote:
I don't think of you as unimaginative, but I think there are other options.
:)
Sure, there must be a way to kill a script that's burning your CPU but it
doesn't have to be a dialog.
That's fine, I guess I
On Aug 12, 2013, at 5:43 PM, David Bruant bruan...@gmail.com wrote:
- I see *no* reasonable alternative to runaway microtask churn other than
slow-script dialog.
So did Dominic [1]. I suggested something else [2] and he found the idea
interesting. What do you think?
Quoting you from
[2]
On Aug 12, 2013, at 6:32 PM, David Bruant bruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash -- the web equivalent of this application has stopped
responding. You might as well ask for a solution to the halting problem! :)
Dave
On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer a...@rauschma.de wrote:
This makes a lot of sense. It would obviate the need for braces, right?
No, at least not for imports. This is only about exports. I'd argue we should
keep the braces on export { x, y, z } for symmetry with imports.
Dave
On Jun 6, 2013, at 11:05 AM, Axel Rauschmayer a...@rauschma.de wrote:
OK, so you don’t want to replace
import foo from single_export_module;
with (braceless!)
import default as foo from single_export_module;
That's correct, I don't want to use `import default`.
Dave
On Jun 5, 2013, at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
It occurs to me that this is valid under the current grammar:
import { default as foo } from foo;
export { foo as default };
We've discussed using a well-known symbol for the default export, but this
simple
On Jun 4, 2013, at 6:31 AM, Kevin Smith zenpars...@gmail.com wrote:
Looks good, but I'm thinking that this should probably _not_ be allowed:
import {,} from x;
Right you are! Fixed, thanks.
Dave
___
es-discuss mailing list
On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo dopazo.j...@gmail.com wrote:
Now that it's been decided that braces are not a form of destructuring and
the colon replaced with `as`, what's the benefit of using braces? Why not
this previous proposal?
import foo as foofoo from foo;
On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer a...@rauschma.de wrote:
Bikeshedding:
Well, here comes a fun thread...
Rationale:
– Reducing the grawlix factor.
– Making non-default imports more convenient – which I assume will happen
more often(?)
That's what this comes down to: do you
On Jun 3, 2013, at 9:33 AM, Yehuda Katz wyc...@gmail.com wrote:
On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam
Tobin-Hochstadt
I would just write `import {} from someModule;`
That
On Jun 3, 2013, at 12:24 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Ah, that makes sense! It's a nice way of prohibiting `scriptexport function
foo() { }/script` as well, assuming inline `script` corresponds to
`Script`. It would be helpful to update the wiki with this, or more
On May 9, 2013, at 6:30 AM, Andreas Rossberg rossb...@google.com wrote:
In your scheme, I honestly cannot tell. Which ones are absolute
logical module names, which ones are relative logical module names,
and which ones are relative URLs?
I realized I left this sub-thread hanging. While I
On May 15, 2013, at 10:42 AM, Andreas Rossberg rossb...@google.com wrote:
(1) Change the set-up of .ondemand calls.
(2) Change the invocation of your bundling tool.
As soon as you have to go there, you've lost almost all advantages of
the ID-based declaration form. Its assumed convenience
On May 13, 2013, at 10:51 AM, Andy Wingo wi...@igalia.com wrote:
If I'm implementing an iterator via a generator and I have to perform
a inner-iteration over an contained iterable (for example, some sort
of flattening operation) the way I code that inner iteration shouldn't
depend upon
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It closes down this whole edge-case focused discussion and that's valuable in
itself. Also, since it turns try {yield expr} finally{} into a syntax error
we could revisit the decision in a future edition if
On May 10, 2013, at 7:18 AM, Andreas Rossberg rossb...@google.com wrote:
Can you explain how one form of module declaration is easier to move
around? In a single script there surely is no difference.
Clients of a module can write:
import { f } from foo;
and regardless of how the module
On May 13, 2013, at 6:11 PM, Brendan Eich bren...@mozilla.com wrote:
We've been over this at least twice. Let's get it right. No close, yield in
try-with-finally ok.
+1
Merge next and send by letting next take an optional parameter? Ok by me.
+1
Make yield* work on any {next, throw}, not
On May 13, 2013, at 4:15 PM, David Herman dher...@mozilla.com wrote:
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It closes down this whole edge-case focused discussion and that's valuable
in itself. Also, since it turns try {yield expr} finally
On May 8, 2013, at 7:39 AM, Andreas Rossberg rossb...@google.com wrote:
On 7 May 2013 21:17, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg rossb...@google.com
wrote:
My point on the topic of external naming is that the language (1)
should not
On May 8, 2013, at 8:05 AM, Andreas Rossberg rossb...@google.com wrote:
You seem to believe otherwise, but I think you still need to explain
how any of the above cases is not sufficiently (or even superiorly)
supported by lexical modules + the loader API.
The most important flaw of this is
On May 2, 2013, at 6:25 AM, Andreas Rossberg rossb...@google.com wrote:
On 1 May 2013 02:06, David Herman dher...@mozilla.com wrote:
It also has a smell to it: the idea that an expression can cause a return,
without the syntactic appearance of `return`. (I'm not opposed to the idea
of being
1 - 100 of 654 matches
Mail list logo
