Re: Proxy performance: JIT-compilation?

On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock wrote: > > On Aug 4, 2017, at 2:22 PM, Mark S. Miller wrote: > > At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea (that > we should turn into a proposal) for a subtle change to

Re: Maximally minimal stack trace standardization

On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg rossb...@google.com wrote: On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: That's why, IIRC (haven't checked lately), TCO is only specified for calls from non-sloppy functions. PTC (Proper Tail

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote: I really have no idea what the behavior should be in the faces of optimized tail calls (which is must broader than simply self recursive methods that can be rewritten as a loop). I've seen various suggestions (a capped

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote: The issue is the asymptotic space consumption almost-contract. The reason I say almost is that conformance of an implementation is not testable. Currently, the spec says nothing about when an implementation might run out

Re: Maximally minimal stack trace standardization

. -Filip On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote: The issue is the asymptotic space consumption almost-contract. The reason I say almost is that conformance of an implementation

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo fpi...@apple.com wrote: On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: I think this would be a mistake -- as I mentioned, there are a number of possible strategies for stack traces w/ proper tail calls, But we

RE: dynamic synchronous import

On Sep 28, 2014 1:07 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of John Lenz I would like to see some way to preload everything, and be able to retrieve them synchronously, something like: Sounds like a good

Re: include

Why not: import {} from 'foo'; or import * as f from 'foo'; This is assuming that there are no other desired exports -- if there are, then the case is even easier. Sam On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com wrote: In the module system we issue import

Re: ModuleImport

On Thu, Jun 19, 2014 at 2:29 PM, Chris Toshok tos...@gmail.com wrote: Calvin's suggestion would allow the following refactoring to be done by the module author without impacting his users, something not possible with current ES6: ```js // a.js V1 export default { C: class C { ... } }

RE: ES6 modules (sorry...)

On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian ecmascr...@cscott.net Using destructuring syntax for imports would be a *good thing*. It builds on our existing understanding of JS

Re: Rationale for dropping ModuleImport syntax?

On Wed, Jun 11, 2014 at 4:39 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss es-discuss-boun...@mozilla.org on behalf of Matthew Robb matthewwr...@gmail.com Transpile aside, I don't want that performance concern. Most of the time I want a real solid reference and

Re: Bytecode

I think this is the definitive post: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html Sam On May 16, 2014 12:54 PM, Russell Leggett russell.legg...@gmail.com wrote: Regarding the original topic of this thread: I think there have been many many prior discussions of a

Re: Promise.cast and Promise.resolve

On Wed, Feb 5, 2014 at 1:34 PM, Andreas Rossberg rossb...@google.com wrote: On 5 February 2014 18:35, Domenic Denicola dome...@domenicdenicola.com wrote: The evolution of DOM and ES promises, and the related fragile consensuses, has been an involved process. Going back to the source

Re: Promise.cast and Promise.resolve

On Tue, Jan 28, 2014 at 7:47 PM, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: Seriously, Haskell calls it=. Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it pronounced b-i-n-d always, monads or not? No, it's always called bind in Haskell. The

Re: multiple modules with the same name

This is absolutely necessary for polyfilling. Imagine that some browser has an ok-but-not-complete implementation of the X library, but you want to use jQuery 17, which requires a better version. You need to be able to replace X with a polyfilled update to X, and then load jQuery on top of that.

Re: New ES6 spec draft (Rev 22, Jan 20, 2014)

On Tue, Jan 21, 2014 at 9:29 AM, Kevin Smith zenpars...@gmail.com wrote: 2) The current loader is an instance of the Loader type. It is incongruent to name an instance with a capitalized identifier. I believe it would be more appropriate to provide access to the current loader via a

Re: Exporting a Module Instance Object

Yes, this should work fine. On Mon, Dec 9, 2013 at 8:59 AM, Kevin Smith zenpars...@gmail.com wrote: Is it possible to export a module instance object? module x from x; export { x }; I believe this should be allowed. I'm not aware of a technical reason why it shouldn't, and not

Re: Modules vs Scripts

On Nov 18, 2013 7:17 AM, Brian Di Palma off...@gmail.com wrote: Correct me if I'm wrong David but module import/exports are not dynamic which allows tooling/IDEs to be more intelligent and programmers to easily understand what dependencies a module has/provides? Yes, that's correct, if I

Re: Modules vs Scripts

the complete imports and exports of the module without having to execute the module. The execution of the module will not dynamically increase it's imports/exports. For instance could you have a Math.random that decides if a dependency is required? On Nov 18, 2013 1:33 PM, Sam Tobin-Hochstadt sa

Re: optional yield expression creates ambiguity

On Sun, Nov 10, 2013 at 1:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The actual utility of a YieldExpression in an 'extends' clause seems so low that I don't think we should make the entire expression grammar more complicated just to support alternative #3. It would be possible to

Re: Module: export *

in the wiki page, and fully specified in the spec documents in the js-loaders repository https://github.com/jorendorff/js-loaders (although there's lots of churn in some parts of those documents). Sam On Thu, Oct 31, 2013 at 10:39 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote

Re: Module: export *

This exports all of the declarations defined in the current module. So: ``` let x = 1; class foo {}; export *; ``` exports both `x` and `foo`. Sam On Thu, Oct 31, 2013 at 10:02 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: Both the wiki and the ES6 draft have the following as valid

Re: Generic Bundling

On Sat, Oct 26, 2013 at 9:05 AM, François REMY francois.remy@outlook.com wrote: Bundling in general is not going to be a valid approach for any purpose related to efficiency soon (except maybe archive-level compression where grouping similar files may improve compression rate slightly).

Re: ToModule and new Module

On Wed, Sep 11, 2013 at 10:28 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: What does the following do? var x = 1; var m = new Module({ get x() { return x; } }); print(m.x); x++; print(m.x); // ??? Does ToModule do a [[Get]] or does it keep the accessor? [[ToModule]]

Re: External and internal modules

On Mon, Sep 9, 2013 at 3:33 AM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: 2. As I understand, this `module foo { ... }` way of defining is either for inner modules (inside a parent external modules), or inside an external file which is not a module, but a script (and therefore,

Re: Module Loaders - module declarations in builds

I think one of us is confused here. How are you importing from 'foo.js'? If you're importing from it, expecting that it's the body of a module, then you'll get a syntax error -- modules don't nest. You could configure the loader so that it treats 'foo.js' as containing the definition of the 'foo'

Re: Modules: error handling when importing declaratively?

On Sun, Jul 28, 2013 at 5:09 PM, Axel Rauschmayer a...@rauschma.de wrote: http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders When you import a module programmatically, you have an error callback: Loader.prototype.import( name, callback, errback, referer = null ) How do you

Re: [module] dynaimic namespace/scope

On Thu, Jul 11, 2013 at 8:24 AM, Kevin Smith zenpars...@gmail.com wrote: Why allow global scope to leak into a new module? That would require a tedious preamble for pretty much any bit of code you want to write. We agree, that's why we haven't tried to do this. How about performing free

Re: [module] dynaimic namespace/scope

On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote: It gets created nowhere, This is right. because the body of a module is implicitly strict, And this is right. so the above code produces a Reference Error. But this is incorrect, because modules check that their

Re: [module] dynaimic namespace/scope

On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote: On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron waldron.r...@gmail.com wrote: It gets created nowhere, This is right. because the body of a module

Re: [module] dynaimic namespace/scope

On Wed, Jul 10, 2013 at 9:14 PM, Mark S. Miller erig...@google.com wrote: On Wed, Jul 10, 2013 at 6:06 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: No, that's not what I mean. The semantics we've discussed multiple times are that modules are compiled with respect to the global object

Re: [module] dynaimic namespace/scope

On Wed, Jul 10, 2013 at 10:12 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 10, 2013, at 6:06 PM, Sam Tobin-Hochstadt wrote: On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote: On Wed, Jul 10

Re: Why does Array.from accept non-iterable arraylikes?

On Tue, Jun 25, 2013 at 11:30 AM, Jason Orendorff jason.orendo...@gmail.com wrote: I think TC39 made @@iterator a symbol on the theory that users would want to build iterable Proxy-based string-key maps that would support property-access syntax. My recollection is that we chose to make

Re: Why does Array.from accept non-iterable arraylikes?

On Tue, Jun 25, 2013 at 11:58 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Jun 25, 2013 at 10:42 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I think TC39 made @@iterator a symbol on the theory that users would want to build iterable Proxy-based string-key maps that would

Re: Standard modules - concept or concrete?

On Jun 20, 2013 7:53 PM, James Burke jrbu...@gmail.com wrote: On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote: I wonder, though, if this might create issues for polyfilling

Re: Modules Loader.load function

On Fri, Jun 21, 2013 at 6:00 PM, Guy Bedford guybedf...@googlemail.com wrote: I see there are now two load functions for the ES6 module loader - 'Loader.import' and 'Loader.load'. Loader.import seems to apply the full normalization process, while Loader.load takes a url directly. This sounds

Re: Standard modules - concept or concrete?

On Thu, Jun 20, 2013 at 9:55 AM, Kevin Smith zenpars...@gmail.com wrote: I would think the advantage of running compile-time checks against the global object is that it can catch errors that we currently use linters for: // OOPS - forgot this line! // import { x } from foo;

Re: Standard modules - concept or concrete?

On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote: I wonder, though, if this might create issues for polyfilling: // polyfillz.js if (this.Promise === void 0) this.Promise = function() { ... } // main.js import polyfillz.js; new

Re: Standard modules - concept or concrete?

On Tue, Jun 18, 2013 at 11:29 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Sam Tobin-Hochstadt This is close, but not quite right. The rule is that any unbound variables in modules are errors. The variables may be bound by import declarations, or by lexical bindings

Re: Standard modules - concept or concrete?

First, I meant what I said in my previous email -- that program is a compile time error inside a module. Second, the meaning of that program doesn't change in strict mode. If the reference is evaluated before the assignment, it's a ReferenceError even in non-strict mode. If the assignment is

Re: Standard modules - concept or concrete?

On Wed, Jun 19, 2013 at 11:37 AM, Kevin Smith zenpars...@gmail.com wrote: OK - I see it on the wiki here: Compilation resolves and validates all variable definitions and references It still seems odd to me that we're going to check a dynamic object (the global object) at link-time for

Re: Translate hook

This is a misunderstanding of the `translate` hook in particular, and the concept of hooks in the loader in general. The loader hooks are there for programmers to configure and change the default behavior of the browser. For example, you could modify the standard loader, or create a new loader,

Re: Conflicts using export *

Yes, this is fine. On Mon, Jun 17, 2013 at 3:38 PM, Kevin Smith zenpars...@gmail.com wrote: Related: is it permissible to bind more than one local name to a single remote target? // foo.js export var x; // main.js import { x as x1, x as x2 } from foo; { Kevin }

Re: Conflicts using export *

On Fri, Jun 14, 2013 at 3:48 AM, Andreas Rossberg rossb...@google.com wrote: What about: // M.js export * from foo; export * from foo; // foo.js export var x = 1; Or: // M.js export * from foo; export * from bar; // foo.js export * from

Re: Conflicts using export *

On Fri, Jun 14, 2013 at 4:57 AM, Claus Reinke claus.rei...@talk21.com wrote: This is a static error. On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith zenpars...@gmail.com wrote: Take the following situation: // M.js export * from foo; export * from bar; I am confused: I thought

Re: Array#sort() implementations not interoperable

On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com wrote: On 14 June 2013 10:17, David Bruant bruan...@gmail.com wrote: I'm suggesting to make the [[Get]], [[Put]] and [[Delete]] sequence less implementation-dependent which means at least to bound them to the maximum of what

Re: Array#sort() implementations not interoperable

On Fri, Jun 14, 2013 at 9:43 AM, Andreas Rossberg rossb...@google.com wrote: On 14 June 2013 14:11, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com wrote: I don't see much of a use case for an array with getters, let alone

Re: Precedence of yield operator

On Fri, Jun 14, 2013 at 11:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Using generators for async is a clever hack, but it's just a hack. A proper solution will need a new keyword anyway (most languages seem to use await or something similar), which can get the better precedence. This

Re: Conflicts using export *

This is a static error. On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith zenpars...@gmail.com wrote: Take the following situation: // M.js export * from foo; export * from bar; // foo export var x = 1; // bar export var x = 2; What is M.x bound to? foo.x (1),

Re: JSON Duplicate Keys

On Sun, Jun 9, 2013 at 10:25 PM, Brendan Eich bren...@mozilla.com wrote: Paul Hoffman wrote: Thanks, but that doesn't match what Yehuda said. If anything, it shows that there is as widespread disagreement within TC39 as to what is a breaking change with respect to duplicate names in objects

Re: Standard modules - concept or concrete?

On Sat, Jun 8, 2013 at 5:08 AM, Brian Di Palma off...@gmail.com wrote: The standard modules wiki page ( http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard ) is not clear as to whether what it describes is a concrete proposal and that ES6 will include it or it's purely a concept.

Re: Custom module loaders and script tags

On Fri, Jun 7, 2013 at 11:29 PM, Guy Bedford guybedf...@googlemail.com wrote: I'm trying to work out how custom module loaders can be used with standard script tags. For example, say I create a RequireJS-style loader (with an identical configuration API including map config etc), and want to

Re: Modularity: ES6 modules vs. HTML imports vs. asm.js

HTML imports are importing HTML, not JS. Coordination is always good, but I don't know what that would entail here. asm.js modules have some specific needs, and it may or may not be able to use ES6 modules. I'll let Dave speak to that. Sam On Sat, Jun 8, 2013 at 9:56 AM, Axel Rauschmayer

Re: Standard modules - concept or concrete?

On Sat, Jun 8, 2013 at 2:00 PM, Brian Di Palma off...@gmail.com wrote: Good, I like the standard modules idea. On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The global object will still be accessible in modules. Of course, you can create new module loaders

Re: Standard modules - concept or concrete?

On Sat, Jun 8, 2013 at 2:30 PM, Brian Di Palma off...@gmail.com wrote: On Sat, Jun 8, 2013 at 7:07 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I think you misunderstand. The requirement that modules not have free variables at compile time *includes* global references. I expect

Re: Custom module loaders and script tags

. We expect that modifying the System loader will be common, and creating new Loaders will be reserved for when new isolated context are required. Sam On 8 June 2013 06:47, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Jun 7, 2013 at 11:29 PM, Guy Bedford guybedf...@googlemail.com wrote

Re: May 21, 22, 23 TC39 Meeting Notes

On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith zenpars...@gmail.com wrote: - The semantics of lexical modules are not really in dispute This is not correct. Andreas, Dave, and I spend a lot of time working on the semantics of lexical modules, and there are significant difficulties. If you get rid

Re: May 21, 22, 23 TC39 Meeting Notes

On Tue, Jun 4, 2013 at 9:45 AM, Andreas Rossberg rossb...@google.com wrote: On 4 June 2013 15:31, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith zenpars...@gmail.com wrote: - The semantics of lexical modules are not really in dispute

Re: Minor questions on new module BNF

On Sun, Jun 2, 2013 at 11:59 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Sam was saying that http://wiki.ecmascript.org/doku.php?id=harmony:modules is up to date. If so, I'm seeing a few things missing from the BNF. It would be great to get these clarified so people can start

Re: May 21, 22, 23 TC39 Meeting Notes

On Sun, Jun 2, 2013 at 4:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Promises vs Monads MM: Continuing from yesterday AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl STH: Don’t like resolve but not willing to die on this hill. AR: DOM has a bunch of ad hocs APIs to

Re: The Paradox of Partial Parametricity

On Fri, May 24, 2013 at 1:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: AP3 (recursive unwrapping of the return value of .then()) doesn't give Q people the guarantees they want (.then() callbacks always receive a plain value), nor does it give monadic people the flexibility they want

Re: The Paradox of Partial Parametricity

On Sat, May 25, 2013 at 1:30 PM, Brendan Eich bren...@mozilla.com wrote: Sam Tobin-Hochstadt wrote: In the meeting, there were (a) people advocating for styles of programming along the lines that you (Tab) have put forward, like me, (b) people advocating for Q-style programming, like Mark

Re: Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)

On Fri, May 24, 2013 at 5:52 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, May 24, 2013 at 2:35 PM, Ron Buckton rbuck...@chronicles.org wrote: Another way to look at this is that there is no way to prevent a caller from using methods from the superclass on a subclass. In other OO

Re: Module naming and declarations

On Wed, May 22, 2013 at 11:27 AM, Andreas Rossberg rossb...@google.com wrote: On 21 May 2013 03:41, David Herman dher...@mozilla.com wrote: 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

Re: Overriding Map/etc with get/set hooks?

On Mon, May 20, 2013 at 10:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: All of these are easy to do if this is just a Map (or has Map on its prototype chain), but with a custom [[MapData]] whose behavior is defined by my spec. Would another way to think about this be as a regular

Re: Overriding Map/etc with get/set hooks?

On Mon, May 20, 2013 at 11:17 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 20, 2013 at 11:10 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, May 20, 2013 at 10:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: All of these are easy to do if this is just a Map (or has

Re: Overriding Map/etc with get/set hooks?

On Mon, May 20, 2013 at 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 21, 2013 at 7:24 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Is it possible for the environment to change the Map during the turn? IOW, is this always true? m.set(x, 1); assert(m.get(x) === 1

Re: Overriding Map/etc with get/set hooks?

On Mon, May 20, 2013 at 11:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 20, 2013 at 11:24 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Is it possible for the environment to change the Map during the turn? IOW, is this always true? m.set(x, 1); assert(m.get(x) === 1

Re: Overriding Map/etc with get/set hooks?

On Tue, May 21, 2013 at 2:52 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 21, 2013 at 8:11 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Ok, that's what I thought was going on. We can make some other function calls which might mutate the Map, just as with any other Map

Re: Overriding Map/etc with get/set hooks?

On Tue, May 21, 2013 at 3:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 21, 2013 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: No, you don't need to do anything differently. Conceptually, there are three things you need: 1. When the Map is created, before it's

Re: Overriding Map/etc with get/set hooks?

On Tue, May 21, 2013 at 6:52 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 21, 2013 at 12:19 PM, Brendan Eich bren...@mozilla.com wrote: Of course, coercing key type makes the API not Map. So if the bi-directionality is important, this would be a custom Map-like class. I guess I

Re: Module naming and declarations

On Mon, May 20, 2013 at 6:51 PM, Kevin Smith zenpars...@gmail.com wrote: I've provided demonstrations for these claims above. If you have a concise counter argument, let's see it! As always, I am happy to be proven wrong. No, what you provided was a demonstration where you complained about a

Re: Module naming and declarations

On Wed, May 8, 2013 at 1:03 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Jason Orendorff [jason.orendo...@gmail.com] Here's what you would do under the proposal: ```js // import a module in the same package/project import ./controllers as controllers; // import some other

Re: Module naming and declarations

On Wed, May 8, 2013 at 2:08 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] How is this in disagreement with what Jason said? His point is that if you're in the module a/b/c

Re: Module naming and declarations

. Of course, there's a sensible default, but for production sites that will likely not be the right choice. Sam On Wed, May 8, 2013 at 2:22 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu

Re: Module naming and declarations

On Wed, May 8, 2013 at 3:59 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: James Burke [jrbu...@gmail.com] On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola dome...@domenicdenicola.com wrote: This is the core of my problem with AMD, at least as I have used it in the

Re: Module naming and declarations

On Tue, May 7, 2013 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 11:18 AM, Jason Orendorff jason.orendo...@gmail.com wrote: If module names were URLs, that would definitely be the right thing. Module names aren't URLs, though. These aren't static links to

Re: Module naming and declarations

[coming back to this a few days later] On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg rossb...@google.com wrote: On 1 May 2013 00:01, David Herman dher...@mozilla.com wrote: On Apr 29, 2013, at 6:34 AM, Andreas Rossberg rossb...@google.com wrote: ...you are generally assuming the use of

Re: Module naming and declarations

On Thu, May 2, 2013 at 2:13 PM, Andreas Rossberg rossb...@google.com wrote: On 1 May 2013 01:15, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Apr 29, 2013 at 9:34 AM, Andreas Rossberg rossb...@google.com wrote: I brought up [removing module declarations] as a min-max sort

Re: Module naming and declarations

On Tue, May 7, 2013 at 4:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 11:48 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, May 7, 2013 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote: But you are treating them as URLs by default (with a small dose

Re: Module naming and declarations

On Tue, May 7, 2013 at 4:31 PM, Kevin Smith zenpars...@gmail.com wrote: The whole point of my original email to Andreas is that this doesn't work. These names are *not* intended to specify where to find the resource. They *are* intended to be names that different modules can coordinate with.

Re: Module naming and declarations

On Tue, May 7, 2013 at 4:33 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 1:22 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, May 7, 2013 at 4:01 PM, Anne van Kesteren ann...@annevk.nl wrote: How is that not treating it as a URL with a dose of magic by default

Re: Module naming and declarations

On Tue, May 7, 2013 at 4:54 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 1:47 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, May 7, 2013 at 4:33 PM, Anne van Kesteren ann...@annevk.nl wrote: Adding? What's the actual processing model for the default loader

Re: Module naming and declarations

On Tue, May 7, 2013 at 5:12 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 2:00 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: 0. If we have an absolute URL, skip steps 1-3. How do you define this? We currently do not have this concept really. You could parse

Re: Module naming and declarations

On Tue, May 7, 2013 at 5:18 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 2:15 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, May 7, 2013 at 5:12 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 2:00 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu

Re: Module naming and declarations

On Tue, May 7, 2013 at 5:45 PM, 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: In particular, as I mentioned before, you _cannot_ make a mean something

Re: Module naming and declarations

On Mon, Apr 29, 2013 at 9:34 AM, Andreas Rossberg rossb...@google.com wrote: On 26 April 2013 00:27, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Dave has already responded about URIs, URLs, and external names, so I'll focus on lexical modules and module declarations below. This includes

Re: Module naming and declarations

[Responding to these two emails together] On Mon, Apr 29, 2013 at 6:40 AM, Kevin Smith zenpars...@gmail.com wrote: The URLs you're proposing here just *are* logical names, and they aren't in most cases being dereferenced to produce resources, which is the core point of URLs on the web.

Re: Module naming and declarations

On Fri, Apr 26, 2013 at 7:17 PM, David Herman dher...@mozilla.com wrote: On Apr 26, 2013, at 7:27 AM, Kevin Smith zenpars...@gmail.com wrote: I'm not understanding how this strategy will facilitate namespace coordination. I can only see it leading to namespace confusion. There is, of

Re: Module naming and declarations

On Sat, Apr 27, 2013 at 12:22 AM, Kevin Smith zenpars...@gmail.com wrote: And note that Java also does not mandate reverse-DNS, it's just a convention. But in fact, that convention is really annoying and people hate it. Node uses much simpler global names that are reserved via NPM. This does

Re: Module naming and declarations

On Apr 25, 2013 4:00 AM, Brian Di Palma off...@gmail.com wrote: I've been following es-discuss for a short amount of time. I'm a JS dev working on a significant code base, this biases how I perceive ES6 issues. From my viewpoint by far the most important advancements provided by ES6,

Re: Module naming and declarations

First, I appreciate you setting your thoughts down in detail. I think this will help us move forward in the discussion. You write in a later message: Having said that, interoperability with existing module systems was not the main motivation for the change in the proposal, as far as I can

Re: Modules: Curly Free

On Tue, Apr 23, 2013 at 8:55 AM, Andreas Rossberg rossb...@google.com wrote: On 22 April 2013 22:10, David Herman dher...@mozilla.com wrote: On Apr 22, 2013, at 6:48 AM, Andreas Rossberg rossb...@google.com wrote: (And semantics, I presume, because Dave hasn't actually told us how the

Re: Modules: Curly Free

On Tue, Apr 23, 2013 at 9:05 AM, Kevin Smith zenpars...@gmail.com wrote: No, this does not require a semantic extension. I think everyone agrees that environments should not have symbol-named variables. However, this is neither here nor there for module instance objects, which are

Re: Modules: Curly Free

On Tue, Apr 23, 2013 at 9:07 AM, Andreas Rossberg rossb...@google.com wrote: On 23 April 2013 15:02, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Apr 23, 2013 at 8:55 AM, Andreas Rossberg rossb...@google.com wrote: On 22 April 2013 22:10, David Herman dher...@mozilla.com wrote

RE: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

What exactly would be the semantic difference between this and just using 'yield'? Sam On Apr 22, 2013 5:40 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Sam Tobin-Hochstadt [sa...@ccs.neu.edu] I don't see what the point of `await` is in your gist. It looks like all

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Sun, Apr 21, 2013 at 12:21 AM, Mark S. Miller erig...@google.com wrote: I hesitate to put Module Loaders on the above list rather than leaving them in ES6; but it would allow their semantics to rest on event loops and their API to rest on promises. If we can get ES7 out quickly, this need

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Sun, Apr 21, 2013 at 12:56 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Finally, I know a lot of people, myself included, are excited about `await` sugar. That is, the plan would be to use generators + promises in ES6 with the awkwardness that entails; once we know what the

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Sam Tobin-Hochstadt wrote: I don't see what the point of `await` is in your gist. It looks like all of the work is being done by `function^`, which looks to be sugar for creating a function and passing it to a scheduler

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

arbitrary JS value'. I suppose the distinction is really blurry, and you would still have to deal with problems like the object's prototype chain containing callables... On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd

  1   2   3   >