Module naming and declarations

Andreas Rossberg rossberg at
Wed May 8 07:39:26 PDT 2013

On 7 May 2013 21:17, Sam Tobin-Hochstadt <samth at> wrote:
> On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg <rossberg at> wrote:
>> My point on the topic of external naming is that the language (1)
>> should not prescribe any specific naming scheme; (2) should not
>> willfully violate URI semantics; (3) should properly separate it from
>> internal naming.
> (1) No "naming scheme" is prescribed here, unless you mean the
> semantics of relative paths

Well, of course it is. You are prescribing the syntax of logical names
in the form of "module IDs". It's a very specific (and kind of
arbitrary) choice. I'd prefer if we did not bake that into the
language beyond saying "the syntax for external module names is URIs,
a loader can interpret that in whatever way it sees fit".

> (2) As I pointed out in the mail I just wrote in reply to Anne,
> nothing violates URI semantics here.  Logical names are not URIs, and
> thus treating them differently than URIs doesn't violate URI
> semantics.

I disagree, for the reasons I explained.

> (3) Internal naming in the sense you mean is primarily a concern for
> organizing code within a single lexical scope. This is a real issue,
> but it's not nearly as pressing as the other issues here, and I think
> we can safely defer it.

I think it is pressing. Furthermore, it will make parts of the current
design redundant. More on that in another reply.

>> Package managers are great, and I agree that they will (and should)
>> become part of the eco system. But leave design decisions to them, and
>> don't limit their options a priori. I'm not sure why we even disagree
>> on that.
> I think we agree on this.

I think we still disagree, see above.

>>>> More specifically, everything should still play nice with standard web
>>>> mechanisms. For me, the web platform implies that I should be able to
>>>> address modules as remote resources (it's a choice _not_ to use that
>>>> mechanism). That requires that the system allows proper URLs as module
>>>> identifiers.
>>> Fully agreed, and if it wasn't clear, the current system does completely support this. You can use a URL as a module name. In the default browser loader, you can choose to import a module from an explicit URL:
>>>     import { $ } from "";
>>> and it will use that URL both as the logical name and as the place to go and fetch the bits.
>> OK, great! Can I also use such URLs for module definitions then?
> I don't know what you're asking here.

In line with what I said above, string-named module declarations (if
we need them at all) should allow arbitrary URI syntax, and not
prescribe some specific form of logical name. It wasn't clear from
Dave's response (or any of the design notes) whether you intend that
to be the case or not. For symmetry, I hope you do. :)

>> I don't see how it hurts interop. It just means that you have to find
>> a convenient _and_ proper way to embed a logical name space into URLs.
>> I proposed using a schema, but anything that is compatible with URL
>> semantics is OK. Just taking AMD-style strings verbatim is not.
> It hurts interop because AMD-style modules are named as "a/b" and not
> "jsp:a/b". A required prefix would therefore require impedance
> matching somewhere.

No, why? You are just embedding the AMD namespace into the URI
namespace. It's clear where you use one or the other. The loader
plug-in for AMD would perform the (trivial) bijection.

>> It is not something which you can justify with AMD/Node precedence
>> either, since AFAICT these systems do not have the notational
>> overloading between logical paths and URLs that you propose.
> Both AMD and Node *automatically* convert module names like "a/b" into
> URLs (in the AMD case) and file paths (in the Node case).

That wasn't my point. As explained elsewhere, Node does not allow
general URLs in the same syntactic context as module IDs, so does not
have the same issue of syntactic overloading (I still have an issue
with the distinction between "a" and "./a", but it's less serious
outside a URL context). I thought the same was true for AMD, but I
overlooked some of its API corner cases. Seriously, though, that does
not make the idea any better, and AMD's rules are not something I'd
ever want to put into a standard.

>>> There's a reason why the existing systems favor lightweight name systems. They're nicely designed to make the common case syntactically lighter-weight. And they absolutely can co-exist with naming modules directly with URL's.
>> Sure they can coexist. But please not by bastardizing URL semantics.
> Again, these are not URLs.  You can't on the one hand complain that we
> aren't using URLs for names, and then on the other hand complain that
> our treatment of logical names doesn't follow the rules for URLs.

Is my complaint clearer now?


More information about the es-discuss mailing list