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
andexport
syntax - better registering of import statements
- import for templates and arbitrary phases
- integrate into
sjs
(it only runs viagrunt 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:
- special
import
forms signaling your intention/belief about the compiletime status of the imported names - special folder to place source that includes compiletime values (say
"macros/"
) - 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 one day:
#lang "js"
// ...
Eventually we can make this tie into readtables and all the custom language stuff.
import
?
what to compile for runtime After we expand all the macros away what should we do with the runtime import
? Options:
- do nothing,
import
is only for macros. have authors write their own CJS/AMD require statements - emit node
require
statements - do everything es6-module-transpiler does
- 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?