2010/1/15 Mike Samuel <[email protected]>: > 2010/1/15 Kam Kasravi <[email protected]>: >> I guess the problem with examples is their analysis may not surface a >> particular use case. I agree at runtime this example may allow the >> interpreter to not over import. >> The original question about how an interpreter may be >> non-deterministic is whether the rules that determine whether the >> interpreter is lazy or eager have not been defined yet. The example was an >> attempt on my part to >> have the developer drive how aggressive the interpreter is in prefetching >> resources. To summarize, there should be some rules that make each vendors >> interpreter behave like the next one, and there should be a way for the >> developer to make the interpreter prefetch even if the interpreter sees no >> reason to do so. > > I think determinism at the network level is out of scope of a module > system, and may be out of scope of the Ecmascript group. > > Even ignoring network conditions, browsers' wildly different behavior > around deferred scripts, the particulars of request headers, ordering > of scripts, number of simultaneous open connections per host; can all > affect the order in which requests are issued. > Anything that requires deterministic behavior as apparent to a network > observer seems like a non-starter to me. > > If you want a clear description of which resources are and are not > fetched, then that's probably specifiable, but GET requests are > supposed to be idempotent, so I don't know what that would gain > assuming fetches are via GET.
Actually, I'm dumb. idempotence only holds for # of requests >= 1. Obviously, requesting the first time may convey significant information. > Java gets around restrictive definitions on class loading by > separating the loading phase from the initialization phase. Loading > can involve network requests, and can be optimistic. Initialization > happens at well-defined times. Would such a split satisfy the use > cases you have in mind? > >> On Jan 15, 2010, at 4:11 PM, Mike Samuel <[email protected]> wrote: >> >> 2010/1/15 Kam Kasravi <[email protected]>: >> 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. >> >> If the module needs all 3, then it needs to fetch all 3. >> >> But if only one adapter is needed, then there is presumably some code >> somewhere which chooses which adapter. Let's call it the >> bootstrapper. Then the module relationship looks like: >> >> bootstrapper imports YUI-adapter >> YUI adapter imports YUI >> bootstrapper passes adapter to framework as a module parameter >> >> Since modules are first class, and are parameterizable, dependencies >> can be injected without requiring over-import. >> By not importing the adapters that are not needed, the other libraries >> are not imported. >> >> >> >> >> 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
