[e-lang] Module naming and identification
Kevin Reid
kpreid at mac.com
Sun Apr 12 13:30:44 EDT 2009
On Apr 9, 2009, at 20:40, ihab.awad at gmail.com wrote:
> Hi folks,
>
> Kris Kowal and I have been thinking about modules in JavaScript a
> lot. :) Our current proposal (which should be unsurprising to this
> list) contains a loader which turns module identifiers into maker
> functions, which can then be instantiated with some capabilities.
> (For the current stage of our proposal, it is wrapped in a
> "require()" function that uses a "sandbox" abstraction, but this
> fact may be safely ignored because it is just a thin layer on top of
> maker functions.)
>
> So far, we have left somewhat open the question of the syntax and
> semantics of module identifiers. This document, with lots of help
> from Kris and MarkM, is an attempt to address this question a bit:
>
> http://docs.google.com/Doc?id=dfgxb7gk_61d47876fr
>
> Comments welcome as always.
- The notion of naming modules with URIs is good. It would be better
if there was a standardized URI-which-designates-the-data-with-this-
hash -- this would fulfill the use case of "avoid code duplication,
but don't specifically rely on anybody else's server or have to change
the identifier to point at my server".
- Your use of "local names" is confusing to me. I think there are
three namespaces at issue here:
1. The names by which "this program/module" refers to other
modules. These are lambda names, in our terminology.
2. The URI of a "package" -- a global name.
3. An name identifying a "module" within a given "package".
You seem to use the term "local name" for both 1 and 3. Just as you
point out that Perl/Python style module systems conflate these, I
think you should establish clearly distinct terms for them.
- Other than this, your design seems quite nicely similar to the one
in my head that I've been meaning to implement for E -- except that
you call a "package" what I call a "module", and your "modules" would
then be my individual objects in a module. Are your "modules"
namespaces of application-specific objects, or are they such objects
themselves?
(These "application-specific objects" would be such things as makeFoo
functions in an E system.)
--
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang
mailing list