On 11/1/13, 11:32 AM, James Burke wrote:
> On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison <lbljeffmo at gmail.com> wrote:
>> Throwing this out there while I stew on the pros/cons of it (so others can
>> as well):
>> I wonder how terrible it would be to have this API define module bodies in
>> terms of a passed function that, say, accepted and/or returned a module
>> object?
> This would mean allowing `import` and `export` inside a function,
> which starts to break down the semantic meaning of what a module "is",
> and how to refer to them.
No, that's why I said the function generates an instance of a Module 
object imperatively (we're already in imperative definition land with 
this API anyway).
No need for `import` or `export`
> Any function would be allowed to import or
> export. What does that mean? Does a function name now qualify as a
> module ID? Why do import statements use string IDs?
>
> If the function wrapping was restricted to only System.* calls to
> express dependencies, then it loses out on the cycle benefits of
> import and export: it would not be possible to adequately convert a
> module that used export/import to a plain function form.
>
> For me, at least as end user, it seems more straightforward to just
> allow `module 'id' {}`. It also avoids the ugliness of having strings
> of JS inside JS files. I appreciate it may have notable semantic
> impacts though.
>
> James

On 11/1/13, 11:32 AM, James Burke wrote:
> This would mean allowing `import` and `export` inside a function,
> which starts to break down the semantic meaning of what a module "is",
> and how to refer to them.

No, that's why I said the function generates an instance of a Module 
object imperatively (we're already in imperative definition land with 
this API anyway).
No need for `import` or `export`