Re: Imports vs. loaded modules

[Kris Kowal]

On Thu, Jan 15, 2009 at 10:28 AM, <ihab...@gmail.com> wrote:
> Hey Kris,
> I suggest we develop the proposal for the time being with the assumption
> that "imports" (arguments to the module function) and "required modules"
> (modules that the module function asks to be loaded and instantiated) are in
> different namespaces.
> Then, once we have a credible idea about the rest, we can decide whether it
> makes sense to separate these name spaces.
> Does this make sense?
> Ihab

That's a fine place to start. Do you recommend a provisional syntax
for the distinction? Does this imply that we should use a completely
distinct syntax for sandbox slurping and module importing, or that we
should partition the name spaces for a single "from import as
using/with" syntax?

Kris

P.S. - the context for this thread is that Ihab and I had a phone call
yesterday and Ihab communicated that he envisioned separate mechanisms
for injecting shared capability objects like "window" and "document"
into a sandbox, or system of cooperating modules. The idea is that
modules themselves are just programs that do not inherently have
"capabilities", like a CPU without a keyboard or monitor. These
communication capabilities must be granted somehow to a sandbox so
that the modules in that system. I had envisioned that these
capabilities would be injected into a sandbox by priming the module
singleton memo with modules that contain capabilities. Ihab's
original vision was that free variables in a module text would
implicitly copy names from the sandbox into the local scope of any
module that uses them. We agreed that this implied a contract between
the sandbox and modules written for that kind of sandbox that there
were reserved names like "window" that a module could opt to adopt,
but not rename. I contend that the syntactic variations on import,
from import, and as provide a fantastic interface for adopting names
from other objects, albeit the sandbox's capability object namespace
or its module name space. I proposed that we should unite the
facilities, but we have reservations about name space collisions. One
possibility is to consider string literal module references distinct
from variable name references:

- import window
- import "module"

At this point, we agree to keep the namespaces distinct since, if it
is deemed desirable, we can merge the name spaces later. One of the
reasons for suspecting that it would be undesirable to merge the
namespaces is that we, as yet, do not intend to constrain the naming
convention for modules, which might be dot delimited variable names,
URL's, URI's or any such names deemed useful in a particular context.
Since each sandbox can define its own "require" function, the naming
convention can be deferred to the implementor of the sandbox; on this
we are in agreement as of yesterday. I am still a proponent of
simplifying the specification; that is, I think that injecting
capability objects into the module instance memo is behaviorally
equivalent to injecting them into another name space, but has the
advantage of harnessing a single syntax for copying variable names
from remote objects. In both cases, modules and capability objects,
the sandbox implementor has the right to determine the naming
convention, so it's not a risk that they would design a name space
collision between the two.

Also, we have not yet decided on whether to a syntax where module
identifiers have reflexive variable names. For example:

import document; --> var document = require("document");

This class of syntax would only be useful if the module identifiers
were also valid JavaScript variable names, or reference chains. Thus,
even though we do not enforce this naming convention (since the user
can opt to use a string literal module identifier and the "as"
clause), we would at least be encouraging the use of dot delimited
module identifiers.

[ihab...@gmail.com]

On Thu, Jan 15, 2009 at 1:44 PM, Kris Kowal <cowber...@gmail.com> wrote:

That's a fine place to start.  Do you recommend a provisional syntax

for the distinction?  Does this imply that we should use a completely
distinct syntax for sandbox slurping and module importing, or that we
should partition the name spaces for a single "from import as
using/with" syntax?

I think we should use different syntax, and I recommend the *provisional* use of --

  @param foo

for the sandbox slurping, vs. various forms of "import" or what not for the module importing. The advantage of "@param" is that it is so ugly we *must* revisit it in favor of something else. :)

I liked your summary of our call; thank you *so* much for that!

Ihab

--
Ihab A.B. Awad, Palo Alto, CA