Module naming and declarations

Andreas Rossberg rossberg at
Thu May 9 06:30:34 PDT 2013

On 9 May 2013 08:15, David Herman <dherman at> wrote:
> On May 8, 2013, at 7:39 AM, Andreas Rossberg <rossberg at> wrote:
>> 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".
> There's something I fear may be getting missed in this conversation. Maybe you were aware but I think it's important to clarify.
> The naming policy we're talking about here is purely for the web's default System loader, not baked into the core language. In the core language, the semantics of module names is that they are strings, nothing more. The core semantics doesn't care what's in those strings. IOW: "the syntax for module names is strings, a loader can interpret that in whatever way it sees fit."
> Note that requiring them to be a URI would be strictly *more* of a policy.

Thanks for clarifying. I am aware of the distinction, but I wasn't
actually sure whether we are on the same page. Because at some point,
e.g. the module notes prescribed names of the form "a/b/c" in module

So yes, we are talking about the loader. And yes, the loader should
use URIs. They are the natural choice, the most general mechanism,
well established, and well-understood. In particular, the loader table
should be indexed by fully resolved, absolute URIs. Everything else
will just create a semantic mess.

>>> The point I'm making is that logical names aren't URLs, they aren't
>>> specified to be URLs, and thus treating them differently isn't a
>>> violation of the meaning of URLs.
>> It is, if logical names (1) syntactically overlap with URI references,
>> (2) are used in places where you also allow URI references, and (3)
>> have a meaning different from (and incompatible with) the respective
>> sublanguage of URI references. Unfortunately, your design is doing
>> exactly that.
> I think this is the crispest statement of your objection to the browser's module name syntax. I feel you are being absolutist: the syntax is simply the (disjoint!) union of absolute URI's and a separate production (one that happens to overlap with URI references, but they are simply not part of this language). This is perfectly well-defined. It's simply a different grammar than that of general URI's. It just happens to overlap in some ways.

I don't know your definition of "disjoint", but it doesn't seem to
match mine. ;)

> Now, you can argue that that design is *confusing*, because the presence of absolute URL's might lead a user to conclude incorrectly that something that isn't an absolute URL has the semantics of a URI reference. I think that's a fair objection, as far as it goes (although I personally disagree). You are overreaching, however, to say that it's a "violation" or suggest that it's some sort of fundamental unsoundness.

Look, consider the following names:


Elsewhere on the web, or (ignoring the last ones) in a file system,
they would all be interpreted in a consistent manner (and moreover,
the first 7 would all be deemed equivalent).

In your scheme, I honestly cannot tell. Which ones are absolute
logical module names, which ones are relative logical module names,
and which ones are relative URLs? Where does a path starting with "a"
denote a relative URL reference and where doesn't it? When does it
make a difference to add a "./" to a path? When is a path starting in
"./a" relative to a referrer's module name and when is it relative to
a referrer's URL? How can I write a relative URL when I need one? Or
short, WAT?

Note that this is not only confusing for human readers, it can also be
a pitfall for libraries or tools that rewrite module references,
because the non-overlapping sublanguage of URLs won't be closed under
some common transformations.

Also, why reinvent something URLs already do? AFAICT, your scheme
introduces two completely separate notions of relative path, that are
interpreted on different levels, and apply based on subtle syntactic
differences. If you embed logical names into URIs, you get all that
for free, and consistently so.

> But let's look at the options here. We're talking about a syntax that allows for a user to specify either a logical name or a URL. So the syntax needs to accommodate those two cases. I see three basic categories of alternatives:
> Option 1: distinguish the cases explicitly by injecting them into a common super-language
>   e.g.: "{ 'path': 'a/b/c' }" and "{ 'url': '' }"
>   e.g.: "jsp:a/b/c" and ""

No new "super language", URIs _are_ that language. They where designed to be!

> Option 2: distinguish the cases implicitly by exploiting their syntactic disjointness
>   e.g.: "a/b/c" and ""
> Option 3: distinguish the cases explicitly by *only* injecting one case into a syntactically disjoint wrapper
>   e.g.: "a/b/c" and "url("
> My issue with Option 1 is that it taxes the common case of logical names with extra boilerplate. Littering entire programs with jsp: at the beginning of every module name is just a non-starter.

Every _non-relative_ module _import_ only. Calling that a non-starter
seems to be your subjective opinion. To me, it adds clarity and
prevents ambiguity.

By the same argument, I could complain that your scheme litters every
relative import with ./ at the beginning. In some Node code I've seen,
for example, that is the more common case.

> However, I actually find something like the example in Option 3 pretty appealing, since it doesn't tax the common case, and it uses a familiar syntax from CSS. It also makes it possible to admit relative URL's, which seems like a win.

This option is certainly better than 2, but the CSS thing never struck
me as elegant. Nor does it seem to be necessary or preferable 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. :)
> They allow arbitrary *string* syntax, so yes, of course, you can define a module declaratively with a URI as its name.
> (More replies to your next message in a few minutes...)

(Have to reply to that one tomorrow.)


More information about the es-discuss mailing list