Remarks about module import

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Mon Aug 18 16:55:22 PDT 2008


Mark S. Miller wrote:
> On Mon, Aug 18, 2008 at 1:44 PM,  <ihab.awad at gmail.com> wrote:
>> Consider a module file located at the URL --
>>
>>  http://foo.com/someModule.js
>>
>> containing the text --
>>
>>  var isOn = false;
>>  provide
>>      toggle: function() {
>>        document.setBackgroundColor(isOn ?
>>            background : '#ffffff');
>>        isOn = !isOn;
>>      },
>>      set: function() {
>>        document.setBackgroundColor(background);
>>        isOn = true;
>>      };
>>
>> This code has two free variables, "document" and "background", and
>> returns the symbols "toggle" and "set" to the importer.

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'm not sure why 'provide' needs new syntax, though. What's wrong with

   module(function() {
     var isOn = false;
     return {
       toggle: ...,
       set: ...
     };
   });

or

   var isOn = false;
   provide({
     toggle: ...,
     set: ...
   });

?

> I'll note that JavaScript seems strangely in between being an
> expression language and a statement language. For most purposes,
> statements are evaluated only for effect, not value. However, a
> program evaled as a string yields a value as one would expect of an
> expression language.
[...]
> If we decide that a module body is to be treated as an evaled program,
> then Ihab's example above can be simply: [...]

The fact that eval does things differently to the fragment of the
language without eval, doesn't mean that it is a good idea to rely
on those differences when designing new language features.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list