Remarks about module import

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Aug 19 09:25:20 PDT 2008


Brendan Eich wrote:
> On Aug 18, 2008, at 4:55 PM, David-Sarah Hopwood wrote:
> 
>> I really like the general approach and the simplicity of Ihab's proposal.
>> Also I strongly agree that a module should *not* implicitly capture
>> the lexical scope in which it is imported.
> 
> I don't think anyone proposed any such thing. Do you?

Ihab's post said:

# I strongly suggest that the importer supply an explicit map giving
# symbol bindings for the loaded module, i.e., I don't think the
# imported module should automatically inherit the lexical scope at
# the import point. The module's code is typically not under the
# direct control of the importer, so allowing it to schlep all its
# importer's lexical variables is giving it too much dangerous power.

So I assumed that "automatically inherit[ing] the lexical scope" was
something that someone had proposed. (It is very difficult to keep
track of what exactly has been proposed, given the disorganised state
of the wiki.) If not, fine; then there's no need to discuss it further.

>> I'm not sure why 'provide' needs new syntax, though.
> 
> Syntax is (a) often good UI; (b) special form expression where there's 
> no "library" way to say what the special form says.

I said, and meant, that I'm not sure why *'provide'* needs new syntax.
I am not making any assertion about new syntax being useless in
general.

In this case, there *is* a library way to express what the special
form says -- I gave two concrete examples of how that could be done.
a) is only relevant if it can be shown that new syntax provides a
signficantly better UI in this case.

> Why should everything be lambda-coded?

What I suggested is not lambda-coding. It's just using a function call
instead of one specific keyword.

> What if I change your bindings for module and provide? (Maybe I can't; 
> please explain why not.)

The problem that some bindings are relied on to the extent that they
must not be changed, is one that must be solved independently of any
other feature such as a module system. From a security/integrity point
of view there's no reason to treat 'module' or 'provide' as being
different from, say, 'Array' in this respect.

> I'm not being snarky (or not merely ;-). The pre-Harmony extreme of "no 
> new syntax, ever" is dead.

That's a straw-man; I think the position of most of the ES3.1 proponents
was simply "minimal new syntax in ES3.1" ('const' is new syntax, for
example). Anyway, I'm not interested in rehashing old disagreements.

> Asking whether new syntax pays for itself is 
> ok, but the question becomes vacuous when the only demonstration against 
> new syntax begs questions about usability and integrity.

Integrity is addressed above: adding a few *more* names for which
rebinding needs to be prevented makes no difference.

What usability questions? I see no essential difference in usability
between "provide({...});" and "provide ...;"

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list