Module naming and declarations

David Herman dherman at mozilla.com
Wed May 8 23:15:24 PDT 2013


On May 8, 2013, at 7:39 AM, Andreas Rossberg <rossberg at google.com> wrote:

> On 7 May 2013 21:17, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>> On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg <rossberg at google.com> 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.

>> 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.

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.

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': 'http://example.com' }"
  e.g.: "jsp:a/b/c" and "http://example.com"

Option 2: distinguish the cases implicitly by exploiting their syntactic disjointness
  e.g.: "a/b/c" and "http://example.com"

Option 3: distinguish the cases explicitly by *only* injecting one case into a syntactically disjoint wrapper
  e.g.: "a/b/c" and "url(http://example.com)"

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. 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.

> 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...)

Dave



More information about the es-discuss mailing list