Jasvir Nagra http://www.cs.auckland.ac.nz/~jas
On Mon, May 24, 2010 at 6:21 AM, Mike Wilson <mike...@hotmail.com> wrote: > Jasvir Nagra wrote: > > According to your proposal, one.js is doing in essence a text inclusion > of the contents of two.js and as a result is susceptible to the > problems unhygienic macro expansion suffers. > > I have been thinking about similar concerns, but, as the proposal mentions > separate compilation of modules, I'm currently looking upon it as dynamic > scoping rather than macro expansion. Ie, a separately compiled external > module (compiled at "top-level" lexical scope) is instantiated an arbitrary > number of levels down in another module hierarchy and is getting references > to the modules at this location through dynamic scoping. (Maybe my usage of > the term dynamic scoping is not fully on the point but I'm hoping it is > getting the message through) > I've tended to compare it to both macro expansion and dynamic scoping not because those comparisons are necessarily accurate but because the extent to which the comparison holds helps me identify the strengths of the proposal and the pitfalls it could avoid. Another way that I've found very helpful in comparing module proposals (and language constructs in general) is the amount of additional code that I'd have to read as a programmer in order to understand a small changelist (CL) in a language that contains the proposed language feature. So for example if a language contains arguments.caller then given a CL that contains function calls, in order to understand the change, I'd have to look all functions transitively called by functions in the CL to be sure the invariants of the function being changed are maintained. I'd like to express my full respect for that you, David and Sam, have > probably thought a lot on this, but it would still be great if you could add > some discussion around this on the proposal page. > Comparing with Java classes and classloaders, where classloaders can affect > the referential environment for subsequently loaded classes, it looks to me > like every module has the capability to affect the referential > environment of its sub-modules. Ie, each time you create a module you are > also creating an environment. > What is quite an explicit operation in Java (setting up a separate > classloader) is implicit in the proposal, and I'm thinking that there might > be risks associated with this. I'm thinking that both Jasvir and I are > thinking about possible advantages if instead using a dedicated syntax just > for setting up the environment to use for sub-modules? > > Btw, Jasvir, I see that you are using the syntax: > > import JQ; > > in your examples, but as far as I can see the grammar doesn't allow this > form, as all import statements are > Oops. You're right. I should say "import JQ.*". > about aliasing names inside a module to local names. I, too, think it would > be great to have a simple form that expresses an intent to use a certain > module without binding any of its names. At the moment this seems to be done > like this: > > module JQ = JQ; > > but I'm not sure that is what is intended? > > Best regards > Mike Wilson >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
