comments below...
________________________________ From: Mike Samuel <[email protected]> To: Kam Kasravi <[email protected]> Cc: kkasravi <[email protected]>; es-discuss <[email protected]> Sent: Fri, January 15, 2010 1:45:52 PM Subject: Re: Module system strawpersons 2010/1/15 Kam Kasravi <[email protected]>: > Ihab, Mike - Thanks for the comments. > Yes, my examples confused definition with declaration, thanks for the > corrections. > I think I still have some unanswered questions which I'll try and clarify > as: > 1. I'm still not clear what the module identifier represents. > Something like 'a/b/c' could be a URI or associated with a URI. > Commonjs implicitly adds a '.js' which suggests this maps to a REST > construct. > I think it would be helpful to clarify the above literal, the module.id, > any relation to javascript namespace and a mapping to server resources > since there is > such an overlap with package management. > > 2. If the eagerness of the interpreter is determined by its implementation > we could have lots of indeterminism across interpreters. There should Which sources of indeterminism do you foresee? Is this indeterminism as apparent to a network observer or as apparent to code running in the same interpreter? [Kam] the network observer. A given interpreter may end up making lots of fetches or a few depending when it decided to resolve the import's. > probably be another construct that defines when resources are fetched. > I'm not sure if the interpreter shouldn't be influenced by the > developer. Could you rephrase this last sentence, please? [Kam] as an example. lets say a module contains 3 adapters: one that uses jQuery, one that uses Ext and one that uses YUI. A eager interpreter may fetch all three when evaluating the module. Yet if the choice of what framework to use (jQuery, Ext or YUI) was determined by the developer/user early on, then the interpreter would fetch 2 frameworks without needing to. If the developer had a way to indicating to the interpreter that 2 of the frameworks weren't needed then the behavior of the interpreter would be predictable. > Brendan, do you recall es4 where the concept of a unit was introduced? > There was also some discussion where management and security > where implicitly mapped to the '.' between identifier parts. I cannot find > that reference. > Kam > > ________________________________ > From: Mike Samuel <[email protected]> > To: kkasravi <[email protected]> > Cc: es-discuss <[email protected]> > Sent: Fri, January 15, 2010 11:20:48 AM > Subject: Re: Module system strawpersons > > 2010/1/15 kkasravi <[email protected]>: >> Hi Mike, Ihab: >> >> One factor that would influence eager or lazy fetching is where the >> import keyword may appear within the ecmascript grammar. >> >> The proposal suggests it could appear anywhere >> an identifier could appear. For example: > > I believe it cannot appear where a LeftHandSideExpression is expected > because a function cannot be assigned to. > So no replacing > foo.bar = baz > with > (import ...) = baz > >> 1) function find(name) { >> var name = foo.bar.Baz.find(name); // identifier 'foo.bar.Baz' >> ... >> } >> >> Replacing foo.bar with import would yield >> >> 2) function find(name) { >> var name = (import 'foo/bar').Baz.find(name); > > Provisioning is separate from importing. The above is looking up Baz > on a function instance which normally would be the same as > var name = Function.prototype.Baz.find(name) > > I think normal usage would look like > var name = (import ...)(module, instance, parameters).Baz.find(name) > >> ... >> } >> >> Replacing foo.bar.Baz with import would yield >> >> 3) function find(name) { >> var name = (import 'foo/bar/Baz').find(name); >> ... >> } >> >> I provided 2) and 3) because its not clear where a module definition >> begins. >> The presumption by naming convention is that foo.bar.Baz can be found >> within >> a relative resource named ./foo/bar.js on some server. This metadata needs >> to >> be somehow made available to the javascript runtime. So in some ways >> module's need package info. Let's assume the correct one is 2). >> >> Looking at 2), current javascript behavior is always lazy fetching because >> the above function find > > fetching can be eager, but evaluation happens whenever the ImportExpr > is reached, possibly not at all. > >> may not be called immediately or not at all. The javascript runtime would >> not complain about >> identifiers that are not immediately accessed or not accessed at all. >> >> Doing eager fetching means that we would need to fetch all imports prior >> to eval. >> Impacts are: >> 1. We fetch more than necessary and immediately. User perception is the >> new js runtime is much slower. > > Eager fetching can be done, or can be delayed, or multiple module > definitions could be fetched in the same transaction. The degree of > eagerness is up to the interpreter. > >> 2. We forces all import expressions to be statically defined. >> >> Summary: >> If import can appear in place of an identifier, there is no choice but to >> do lazy fetching. Lazy fetching without CPS (continuation passing style) >> support means you could not do (import foo/bar').Baz.find(name); >> >> >> Kam >> >> >> >> On Jan 14, 2010, at 2:29 PM, Mike Samuel wrote: >> >>> Ok, so let me try to make sure I understand the special form in >>> strawman:modules_emaker_style, by defining a mini-strawman and >>> knocking it down. >>> >>> Consider a special form >>> (f, definer) = defineDelayedFunction(); >>> where f is a function that will block on first call until definer has >>> been called with an arguments array and a function body upon which >>> point it will behave as if it were defined via new Function(...) with >>> those arguments and function body. definer raises an Error on second >>> and subsequent calls. >>> >>> defineDelayedFunction could be used with an async channel like >>> XMLHttpRequest to define a module system, but all module definitions >>> would happen at execute time, so it cannot be used to define a module >>> system that resolves definitions prior to body evaluation. >>> >>> In modules_emaker_style, imports are statically determinable, so the >>> set of dependencies is fully satisfied before the Program is >>> evaluated, and this can be done recursively to make full use of >>> sockets. A browser could optimistically find import definitions and >>> start downloading before the full script body is loaded. >>> >>> defineDelayedFunction would impose lazy fetching, but >>> modules_emaker_style allows eager fetching. >>> >>> >>> 2010/1/14 <[email protected]>: >>>> Hi Mike, >>>> >>>> On Thu, Jan 14, 2010 at 1:29 PM, Mike Samuel <[email protected]> >>>> wrote: >>>>> Are these proposals mutually exclusive or complementary. >>>>> If (1) and (2) are exclusive, is there a place to collect use cases >>>>> for a module-off? >>>> >>>> For my part, I think (1) and (2) are counterproposals, but there may >>>> exist a bunch of cross-pollination. For example, I will probably end >>>> up stealing Kris's "import with" syntax sometime. >>>> >>>>> I don't see the word module anywhere in the packages proposal besides >>>>> footnotes. >>>>> What is the relationship between packages and modules. >>>> >>>> The packages proposal was written with module proposal (1) in mind, >>>> but is compatible in the broad sense with either. It does say in the >>>> beginning that it "... is intended to satisfy the Uniform location and >>>> retrieval goal of modules_emaker_style". There are more details under >>>> "Use in import" (where I just updated the syntax a little bit). >>>> >>>>>> 2. >>>>>> http://wiki.ecmascript.org/doku.php?id=strawman:modules_emaker_style >>>>>> >>>>>> Module proposal, by Ihab, focusing on EMaker-style invocation >>>>>> semantics. >>>>> >>>>> "First class objects. To the extent possible, module system components >>>>> must be represented as first-class ECMAScript objects." >>>>> Does object exclude primitives such as strings, or is the goal to >>>>> exclude abstractions like LexicalScopes and References? >>>> >>>> The point is that module system components are made to appear, to the >>>> extent possible, as first-class objects rather than unmentionable >>>> "static" magic. E.g., contrast Java where, if Foo is a class, the >>>> expression "Foo" by itself is not an object; generic class parameters >>>> are not objects; etc. -- which makes higher-order programming somewhat >>>> harder. >>>> >>>>> "import" is added to the reserved keyword list? >>>> >>>> It should be reserved now, and is for sure reserved according to this >>>> proposal. >>>> >>>>> "return { >>>>> getX: function() { return x; }, >>>>> getY: function() { return y; }," >>>>> indentation >>>> >>>> Fixed, tx. >>>> >>>>> "In the module’s code, this is initialized to a new object that is >>>>> instanceof the module function" >>>>> Does this mean that access to a module instance conveys authority to >>>>> create new module instances? >>>> >>>> Yes. Just like any other ES function where it's return value is >>>> instanceof that function. >>>> >>>>> "An import expression evaluates immediately to a module function >>>>> despite the fact that the specified module may have been fetched by >>>>> asynchronous means (e.g., nonblocking network operations). This is >>>>> done by taking advantage of the fact that import is a special form." >>>>> Does this require "import" to be a special form instead of a >>>>> desugaring? Or can the special form be boiled down to a function >>>>> which when called, delays until another function is invoked, >>>>> presumably with a valid FunctionExpr string as its sole argument? >>>> >>>> Would that require a continuation-passing transform of the code after >>>> the desugared "import"? If so, that may not be semantics preserving. >>>> >>>> Ihab >>>> >>>> -- >>>> Ihab A.B. Awad, Palo Alto, CA >>>> >>> >> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
