[e-lang] Module naming and identification

[Lex Spoon]

On Apr 14, 2009, at 5:01 AM, Kevin Reid wrote:
> On Apr 13, 2009, at 23:49, Brian Warner wrote:
>
>> On Sun, 12 Apr 2009 21:48:09 -0600
>> zooko <zooko at zooko.com> wrote:
>>
>>> Another is the Python "setuptools" tool, which accepts an optional
>>> md5sum in the fragment of a package URL, and if that fragment is
>>> present then setuptools rejects the package downloaded from that URL
>>> if its doesn't match the md5sum.
>>
>> Note that this is an immutable "strong name": there's no facility to
>> say
>> "accept any version of the package which is signed by the following
>> key".


I must say, any form of strong name to a module only seems helpful for  
*binary* distribution, that is, for files sent directly to the web  
browser.  They look bad for source code that you'd check into a  
repository.  I don't think you want to have strong names in those,  
because otherwise people will have to copy and modify your files just  
to fill in different strong names.

Because binary and source code have different requirements, and  
because JavaScript is used for both roles, there seems to be a place  
for both kind of module reference.

One lightweight way to support the two kinds of references would be to  
add module maps to the system.  A module map would map a module  
reference into a strong name.  Given such a thing, what an app can do  
when it starts up is insist it be provided a module map. That map is  
then consulted whenever a require() is reached to know exactly what to  
load.

By having the map centralized in one file, the app will have all its  
choices made at the time it starts up; it won't start out by using  
module versions from app version 1, and then later end up grabbing  
module versions for app version 2.  To contrast, if the app simply  
sends its source-code references to some server for resolution, it  
could end up downloading incompatible versions.

One implication of this arrangement is that the module references  
should ideally be statically analyzable.  Otherwise, it will be  
impossible to implement the tool that generates a module map.

What do folks think: shouldn't there be *two* kinds of cross-module  
reference?

Lex