mozilla/sweet.js — pull request #378 by disnet (2014-08-29 07:47:28+00:00)
Title: ES6 module integration

First stab. Very much work in progress but you can (sort of) `import` compiletime code (macros) and `import` runtime code for use in macros.

Lots more to do:

- test coverage
- more correct `import` and `export` syntax
- better registering of import statements
- import for templates and arbitrary phases
- integrate into `sjs` (it only runs via `grunt single` atm)

Some design questions that still need to be hashed out:

# npm integration

I know @natefaubion has thought a lot about this but basically there's a question of when should we actually expand module from an `import`. Since lot's of modules won't have compiletime exports we could avoid the expense of expansion for the "common" case when you just want to import runtime code (either for use in a macro body or otherwise).

There's a few obvious ways of doing this:

1. special `import` forms signaling your intention/belief about the compiletime status of the imported names
2. special folder to place source that includes compiletime values (say `"macros/"`)
3. file/folder pattern in package.json to signify which source files might contain compiletime values

Option 1 is not good because the user of a library shouldn't know how a form is implemented to use it.

Options 2 and 3 bug me because they both rely on macro package authors to know about this (what is at the end of the day) optimization detail.

Ah! As I was typing this out I thought of a fourth option. Use a pragma at the beginning of all sweet.js sources. This makes it easy to determine if the code might need to be expanded. I think we want to do this anyway as a way of following Racket's tower of [languages](http://docs.racket-lang.org/guide/languages.html) one day:

```js
#lang "js"

// ...
```

Eventually we can make this tie into readtables and all the custom language stuff.

# what to compile for runtime `import`?

After we expand all the macros away what should we do with the runtime `import`? Options:
1. do nothing, `import` is only for macros. have authors write their own CJS/AMD require statements
2. emit node `require` statements
3. do everything es6-module-transpiler does
4. leave `imports` and use es6-module-transpiler as a backend

I think 4 is the best. Not sure if escodegen supports `import` and `export` yet so might need to get that working first. Perhaps 1 to begin with and 4 as the end goal?