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 proxy semantics that
> * should break essent
On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg wrote:
> On 29 September 2014 19:25, Brendan Eich 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 Calls), not TCO. It's confusing
On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo wrote:
>
>
>> On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt
>> 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
ce.
>
> -Filip
>
>
> On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt
> wrote:
>
> On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller wrote:
>
> The issue is the asymptotic space consumption almost-contract. The reason I
> say "almost" is that conformance of
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller 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
> of storage.
On Mon, Sep 29, 2014 at 10:55 AM, John Lenz 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 call
> history) bu
On Sep 28, 2014 1:07 AM, "Domenic Denicola"
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 custom loader extensio
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 wrote:
> In the module system we issue
>import {foo} from 'foo';
>
On Thu, Jun 19, 2014 at 2:29 PM, Chris Toshok 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 { ... }
On Jun 16, 2014 1:06 PM, "Domenic Denicola"
wrote:
>
> From: es-discuss on behalf of C. Scott
Ananian
>
> > Using destructuring syntax for imports would be a *good thing*. It
builds on our existing understanding of JS constructs, instead of adding
more gratuitously different things to learn.
>
On Wed, Jun 11, 2014 at 4:39 PM, Domenic Denicola
wrote:
> From: es-discuss on behalf of Matthew Robb
>
>
>> Transpile aside, I don't want that performance concern. Most of the time I
>> want a real solid reference and the only way to get it as the spec stands is
>> to import something and th
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"
wrote:
>
>> Regarding the original topic of this thread: I think there have been many
>> many prior discussions of a standardised bytec
On Wed, Feb 5, 2014 at 1:34 PM, Andreas Rossberg wrote:
> On 5 February 2014 18:35, Domenic Denicola
> wrote:
>> The evolution of DOM and ES promises, and the related fragile consensuses,
>> has been an involved process.
>>
>> Going back to the source documents, consider what the May AP2
>> pr
On Tue, Jan 28, 2014 at 7:47 PM, Brendan Eich 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 name flatM
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.
On Tue, Jan 21, 2014 at 9:29 AM, Kevin Smith 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
> getter on the Loader
Yes, this should work fine.
On Mon, Dec 9, 2013 at 8:59 AM, Kevin Smith 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 allowing it wou
On Wed, Nov 20, 2013 at 12:35 PM, Brendan Eich wrote:
> I don't quite understand what Benjamin is running into.
I think that Benjamin's point is that generators allow you to use
synchronous programming models instead of async ones. Then your
errors become exceptions instead of errback calls. So,
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, 201
On Nov 18, 2013 7:17 AM, "Brian Di Palma" 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 guess correct
On Sun, Nov 10, 2013 at 1:46 PM, Allen Wirfs-Brock
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 just parenthesize th
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
> wrote:
>>
>
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
wrote:
> Both the wiki and the ES6 draft have the following as valid
> ExportDeclaration:
>
> e
On Sat, Oct 26, 2013 at 9:05 AM, François REMY
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). My point is
> that I'm no
On Wed, Sep 11, 2013 at 10:28 AM, Erik Arvidsson
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]] does a [[Get],
On Mon, Sep 9, 2013 at 3:33 AM, Dmitry Soshnikov
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, cannot be loaded as
> mod
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'
On Sun, Jul 28, 2013 at 5:09 PM, Axel Rauschmayer 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 handle erro
On Thu, Jul 11, 2013 at 8:24 AM, Kevin Smith 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 variable chec
On Wed, Jul 10, 2013 at 10:12 PM, Allen Wirfs-Brock
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
>> wrote:
>>>
>>> On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
>>
On Wed, Jul 10, 2013 at 9:14 PM, Mark S. Miller wrote:
> On Wed, Jul 10, 2013 at 6:06 PM, Sam Tobin-Hochstadt
> wrote:
>>
>>
>> No, that's not what I mean. The semantics we've discussed multiple
>> times are that modules are compiled with respect to the g
On Wed, Jul 10, 2013 at 8:02 PM, Allen Wirfs-Brock
wrote:
>
> On Jul 10, 2013, at 4:40 PM, Sam Tobin-Hochstadt wrote:
>
>> On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron wrote:
>>>
>>> It gets created nowhere,
>>
>> This is right.
>>
&g
On Wed, Jul 10, 2013 at 7:24 PM, Rick Waldron 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 bodies don't
have fr
On Tue, Jun 25, 2013 at 11:58 AM, Jason Orendorff
wrote:
> On Tue, Jun 25, 2013 at 10:42 AM, Sam Tobin-Hochstadt
> 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
&g
On Tue, Jun 25, 2013 at 11:30 AM, Jason Orendorff
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 `iterator` a symbol because
On Fri, Jun 21, 2013 at 6:00 PM, Guy Bedford 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
> like a good feature to
On Jun 20, 2013 7:53 PM, "James Burke" wrote:
>
> On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt
wrote:
> > On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith
wrote:
> >> I wonder, though, if this might create issues for polyfilling:
> >>
> >&
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith 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 Promise();
>
> Thi
On Thu, Jun 20, 2013 at 9:55 AM, Kevin Smith 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";
>
> function someRar
On Wed, Jun 19, 2013 at 11:37 AM, Kevin Smith 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 references. What i
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
eva
On Tue, Jun 18, 2013 at 11:29 PM, Domenic Denicola
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 bin
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, s
Yes, this is fine.
On Mon, Jun 17, 2013 at 3:38 PM, Kevin Smith 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 }
_
On Fri, Jun 14, 2013 at 11:21 AM, Tab Atkins Jr. 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 is just not tru
On Fri, Jun 14, 2013 at 9:43 AM, Andreas Rossberg wrote:
> On 14 June 2013 14:11, Sam Tobin-Hochstadt wrote:
>> On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg
>> wrote:
>>> I don't see much of a use case for an array with getters, let alone
>>> sortin
On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg wrote:
> On 14 June 2013 10:17, David Bruant 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 is needed. That's a gain espec
On Fri, Jun 14, 2013 at 4:57 AM, Claus Reinke wrote:
>> This is a static error.
>>
>> On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith wrote:
>>>
>>> Take the following situation:
>>>
>>> // M.js
>>> export * from "foo";
>>> export * from "bar";
>
>
> I am confused: I thought "import *" w
On Fri, Jun 14, 2013 at 3:48 AM, Andreas Rossberg 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
M.x is the local variable, because otherwise changes in the exports of
`"foo"` could, unbenknownst to M, cause an error.
Also, I misspoke earlier. The error is only if you *use* M.x, for the
same reason.
Sam
On Thu, Jun 13, 2013 at 3:48 PM, Kevin Smith wrote:
> What about the following case?
>
This is a static error.
On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith 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),
On Sun, Jun 9, 2013 at 10:25 PM, Brendan Eich 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 as there so
hod.
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 wrote:
>>
>> On Fri, Jun 7, 2013 at 11:29 PM, Guy Bedford
>> wrote
On Sat, Jun 8, 2013 at 2:30 PM, Brian Di Palma wrote:
> On Sat, Jun 8, 2013 at 7:07 PM, Sam Tobin-Hochstadt wrote:
>>
>> I think you misunderstand. The requirement that modules not have free
>> variables at compile time *includes* global references. I expect that
>&g
On Sat, Jun 8, 2013 at 2:00 PM, Brian Di Palma wrote:
> Good, I like the standard modules idea.
>
> On Sat, Jun 8, 2013 at 2:33 PM, Sam Tobin-Hochstadt wrote:
>>
>> The global object will still be accessible in modules. Of course, you
>> can create new module l
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 wrote
On Fri, Jun 7, 2013 at 11:29 PM, Guy Bedford 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 use this within a
> s
On Sat, Jun 8, 2013 at 5:08 AM, Brian Di Palma 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.
ES6 will defi
On Tue, Jun 4, 2013 at 9:45 AM, Andreas Rossberg wrote:
> On 4 June 2013 15:31, Sam Tobin-Hochstadt wrote:
>> On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith wrote:
>>> - The semantics of lexical modules are not really in dispute
>>
>> This is not correct. Andreas, D
On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith 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 of recursion, and if
On Sun, Jun 2, 2013 at 4:44 PM, Tab Atkins Jr. 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 do pr
On Sun, Jun 2, 2013 at 11:59 PM, Domenic Denicola
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 writing accurate transpilers.
On Sat, May 25, 2013 at 1:30 PM, Brendan Eich 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 programm
On Fri, May 24, 2013 at 1:42 PM, Tab Atkins Jr. 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 (Domenic's proposal
On Fri, May 24, 2013 at 5:52 PM, Tab Atkins Jr. wrote:
> On Fri, May 24, 2013 at 2:35 PM, Ron Buckton 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 languages, its
>> much harder (or nearly i
On Wed, May 22, 2013 at 11:27 AM, Andreas Rossberg wrote:
> On 21 May 2013 03:41, David Herman wrote:
>> On May 9, 2013, at 6:30 AM, Andreas Rossberg wrote:
>>
>>> In your scheme, I honestly cannot tell. Which ones are absolute
>>> logical module names, which ones are relative logical module nam
On Tue, May 21, 2013 at 6:52 AM, Anne van Kesteren wrote:
> On Tue, May 21, 2013 at 12:19 PM, Brendan Eich 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 also do not really get this. S
On Tue, May 21, 2013 at 3:09 AM, Anne van Kesteren wrote:
> On Tue, May 21, 2013 at 11:01 AM, Sam Tobin-Hochstadt
> wrote:
>> No, you don't need to do anything differently. Conceptually, there
>> are three things you need:
>>
>> 1. When the Map is created
On Tue, May 21, 2013 at 2:52 AM, Anne van Kesteren wrote:
> On Tue, May 21, 2013 at 8:11 AM, Sam Tobin-Hochstadt
> 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
>>
On Mon, May 20, 2013 at 11:58 PM, Tab Atkins Jr. wrote:
> On Mon, May 20, 2013 at 11:24 PM, Sam Tobin-Hochstadt
> wrote:
>> Is it possible for the environment to change the Map during the turn?
>>
>> IOW, is this always true?
>>
>> m.set("x", 1);
&g
On Mon, May 20, 2013 at 11:32 PM, Anne van Kesteren wrote:
> On Tue, May 21, 2013 at 7:24 AM, Sam Tobin-Hochstadt
> wrote:
>> Is it possible for the environment to change the Map during the turn?
>>
>> IOW, is this always true?
>>
>> m.set("x", 1);
On Mon, May 20, 2013 at 11:17 PM, Tab Atkins Jr. wrote:
> On Mon, May 20, 2013 at 11:10 PM, Sam Tobin-Hochstadt
> wrote:
>> On Mon, May 20, 2013 at 10:32 PM, Tab Atkins Jr.
>> wrote:
>>> All of these are easy to do if this is just a Map (or has Map on its
>&
On Mon, May 20, 2013 at 10:32 PM, Tab Atkins Jr. 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 plain-old Map,
but which
On Mon, May 20, 2013 at 6:51 PM, Kevin Smith 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 registry for one s
On Wed, May 8, 2013 at 3:59 PM, Domenic Denicola
wrote:
>
> From: James Burke [jrbu...@gmail.com]
>
> > On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola
> > wrote:
> >> This is the core of my problem with AMD, at least as I have used it in the
> >> real world with RequireJS. You have no idea w
like YUI, to map "backbone" to some file somewhere.
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
wrote:
> From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-
On Wed, May 8, 2013 at 2:08 PM, Domenic Denicola
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&q
On Wed, May 8, 2013 at 1:03 PM, Domenic Denicola
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 package
>
On Tue, May 7, 2013 at 5:45 PM, Andreas Rossberg wrote:
> On 7 May 2013 21:17, Sam Tobin-Hochstadt wrote:
>> On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg
>> wrote:
>>> In particular, as I mentioned before, you _cannot_ make "a" mean
>>> somet
On Tue, May 7, 2013 at 5:18 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 2:15 PM, Sam Tobin-Hochstadt wrote:
>> On Tue, May 7, 2013 at 5:12 PM, Anne van Kesteren wrote:
>>> On Tue, May 7, 2013 at 2:00 PM, Sam Tobin-Hochstadt
>>> wrote:
>>>> 0. I
On Tue, May 7, 2013 at 5:12 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 2:00 PM, Sam Tobin-Hochstadt 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 and compare if th
On Tue, May 7, 2013 at 4:54 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 1:47 PM, Sam Tobin-Hochstadt wrote:
>> On Tue, May 7, 2013 at 4:33 PM, Anne van Kesteren wrote:
>>> "Adding"? What's the actual processing model for the default loader
>&
On Tue, May 7, 2013 at 4:33 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 1:22 PM, Sam Tobin-Hochstadt wrote:
>> On Tue, May 7, 2013 at 4:01 PM, Anne van Kesteren wrote:
>>> How is that not treating it as a URL with a dose of magic by default?
>>> E.g. imp
On Tue, May 7, 2013 at 4:31 PM, Kevin Smith 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. Should back
On Tue, May 7, 2013 at 4:01 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 11:48 AM, Sam Tobin-Hochstadt
> wrote:
>> On Tue, May 7, 2013 at 2:35 PM, Anne van Kesteren wrote:
>>> But you are treating them as URLs by default (with a small dose of magic).
>>
On Thu, May 2, 2013 at 2:13 PM, Andreas Rossberg wrote:
> On 1 May 2013 01:15, Sam Tobin-Hochstadt wrote:
>> On Mon, Apr 29, 2013 at 9:34 AM, Andreas Rossberg
>> wrote:
>>> I brought up [removing module declarations] as a "min-max" sort of
>>> comp
[coming back to this a few days later]
On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg wrote:
> On 1 May 2013 00:01, David Herman wrote:
>> On Apr 29, 2013, at 6:34 AM, Andreas Rossberg wrote:
>>
>>> ...you are generally assuming the use of some package manager. This
>>> is a fairly significa
On Tue, May 7, 2013 at 2:35 PM, Anne van Kesteren wrote:
> On Tue, May 7, 2013 at 11:18 AM, Jason Orendorff
> 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 static
>> locations (for reasons discus
On Mon, Apr 29, 2013 at 9:34 AM, Andreas Rossberg wrote:
> On 26 April 2013 00:27, Sam Tobin-Hochstadt wrote:
Dave has already responded about URIs, URLs, and external names, so
I'll focus on lexical modules and module declarations below. This
includes response to a couple other of you
[Responding to these two emails together]
On Mon, Apr 29, 2013 at 6:40 AM, Kevin Smith 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. They're just inco
On Sat, Apr 27, 2013 at 12:22 AM, Kevin Smith 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
>> lead to coll
On Fri, Apr 26, 2013 at 7:17 PM, David Herman wrote:
> On Apr 26, 2013, at 7:27 AM, Kevin Smith wrote:
> > I'm not understanding how this strategy will facilitate namespace
> > coordination. I can
> > only see it leading to namespace confusion.
>
> There is, of course, a need for people to agr
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
On Apr 25, 2013 4:00 AM, "Brian Di Palma" 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, eclipsing all
On Tue, Apr 23, 2013 at 9:07 AM, Andreas Rossberg wrote:
> On 23 April 2013 15:02, Sam Tobin-Hochstadt wrote:
>> On Tue, Apr 23, 2013 at 8:55 AM, Andreas Rossberg
>> wrote:
>>> On 22 April 2013 22:10, David Herman wrote:
>>>> On Apr 22, 2013,
On Tue, Apr 23, 2013 at 9:05 AM, Kevin Smith 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 reflections of modul
On Tue, Apr 23, 2013 at 8:55 AM, Andreas Rossberg wrote:
> On 22 April 2013 22:10, David Herman wrote:
>> On Apr 22, 2013, at 6:48 AM, Andreas Rossberg wrote:
>>
>>> (And semantics, I presume, because
>>> Dave hasn't actually told us how the "anonymous" export would be
>>> distinguished internal
What exactly would be the semantic difference between this and just using
'yield'?
Sam
On Apr 22, 2013 5:40 PM, "Domenic Denicola"
wrote:
> From: Sam Tobin-Hochstadt [sa...@ccs.neu.edu]
>
> > I don't see what the point of `await` is in your gist. It looks
t object, not 'any 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
> wrote:
>
On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd wrote:
> if I called Object.freeze or Object.seal on a JS object would it actually be
> safe to pass it to another thread and let both threads use it without any
> locking or guards?
No, it's not safe. Consider Object.freeze(console.log).
Sam
1 - 100 of 283 matches
Mail list logo
