{"action":"created","issue":{"url":"https://api.github.com/repos/sweet-js/sweet.js/issues/233","repository_url":"https://api.github.com/repos/sweet-js/sweet.js","labels_url":"https://api.github.com/repos/sweet-js/sweet.js/issues/233/labels{/name}","comments_url":"https://api.github.com/repos/sweet-js/sweet.js/issues/233/comments","events_url":"https://api.github.com/repos/sweet-js/sweet.js/issues/233/events","html_url":"https://github.com/sweet-js/sweet.js/issues/233","id":26731433,"number":233,"title":"Integrate sweet.js with ES6 modules","user":{"login":"disnet","id":2362,"avatar_url":"https://avatars.githubusercontent.com/u/2362?v=3","gravatar_id":"","url":"https://api.github.com/users/disnet","html_url":"https://github.com/disnet","followers_url":"https://api.github.com/users/disnet/followers","following_url":"https://api.github.com/users/disnet/following{/other_user}","gists_url":"https://api.github.com/users/disnet/gists{/gist_id}","starred_url":"https://api.github.com/users/disnet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/disnet/subscriptions","organizations_url":"https://api.github.com/users/disnet/orgs","repos_url":"https://api.github.com/users/disnet/repos","events_url":"https://api.github.com/users/disnet/events{/privacy}","received_events_url":"https://api.github.com/users/disnet/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/sweet-js/sweet.js/labels/type:%20feature","name":"type: feature","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":23,"created_at":"2014-02-01T04:01:40Z","updated_at":"2016-09-06T17:59:39Z","closed_at":null,"body":"There are two papers on macros and modules that are probably relevant. [Composable and Compilable Macros](http://www.cs.utah.edu/plt/publications/macromod.pdf) and [Implicit Phasing for R6RS Libraries](http://www.cs.indiana.edu/~dyb/pubs/implicit-phasing.pdf).\r\n\r\nThe basic idea of both papers is that you have to track the phase level any bit of syntax currently is in. The phase isn't as simple as compile-time vs. run-time because a case macro (compile-time) might need to import and use another macro (earlier compile-time) which might also need to use a macro (even *earlier* compile-time) and so on. \r\n\r\n```js\r\n// bar.js\r\nexport macro bar {\r\n    case {_ ()} => {\r\n        // ...\r\n    }\r\n}\r\n```\r\n\r\n```js\r\n// foo.js\r\nimport { bar } from \"bar\"\r\nexport macro foo {\r\n    case {_ () } => { \r\n        bar()\r\n        // ... \r\n    }\r\n}\r\n```\r\n\r\n```js\r\n// main.js\r\nimport { foo } from \"foo\"\r\nfoo()\r\n```\r\n\r\nThe papers outline two approaches we could take. The first, following the \"Composable and Compilable\" paper and Racket, involves explicitly declaring what phase level an import is for. \r\n\r\n```js\r\nimport { $ } from \"jquery\"\r\nimport forSyntax { _ } from \"underscore\"\r\n\r\nlet m = macro {\r\n    case { } => {\r\n        $(\"#foo\") // error: $ not bound\r\n        _.map([1,2,3], function (x) { ... });\r\n        // ...\r\n    }\r\n}\r\n$(\"#foo\") // works fine\r\n_.map(...) // error: _ is not bound\r\n```\r\n\r\nThis gets ugly though when you have a macro definition in your macro definition since you need to import up two phase levels:\r\n\r\n```js\r\nimport { $ } from \"jquery\"\r\nimport forSyntax { _ } from \"underscore\"\r\nimport forSyntax forSyntax { ld } from \"lodash\"\r\n// or maybe following racket:\r\nimport meta 2 { ld } from \"lodash\"\r\n\r\nlet m = macro {\r\n    case { } => {\r\n        let n = macro {\r\n            case {} => {\r\n                ld.map(...)\r\n                // ...\r\n            }\r\n        }\r\n        $(\"#foo\") // error: $ not bound\r\n        _.map([1,2,3], function (x) { ... });\r\n        // ...\r\n    }\r\n}\r\n$(\"#foo\") // works fine\r\n_.map(...) // error: _ is not bound\r\n```\r\n\r\nThe \"Implicit Phasing\" paper gives a technique for tracking all the phasing implicitly so you wouldn't need to do `import forSyntax`. The paper seems to suggest that there are no real trade offs in doing this but I seem to remember @dherman mention there was a good reason Racket stayed with explicitly phase labeling (something about the REPL maybe?). \r\n\r\nI would prefer to keep the phasing implicit if possible since forcing macro authors to think about the details of module phasing seems not great.\r\n"},"comment":{"url":"https://api.github.com/repos/sweet-js/sweet.js/issues/comments/245035401","html_url":"https://github.com/sweet-js/sweet.js/issues/233#issuecomment-245035401","issue_url":"https://api.github.com/repos/sweet-js/sweet.js/issues/233","id":245035401,"user":{"login":"disnet","id":2362,"avatar_url":"https://avatars.githubusercontent.com/u/2362?v=3","gravatar_id":"","url":"https://api.github.com/users/disnet","html_url":"https://github.com/disnet","followers_url":"https://api.github.com/users/disnet/followers","following_url":"https://api.github.com/users/disnet/following{/other_user}","gists_url":"https://api.github.com/users/disnet/gists{/gist_id}","starred_url":"https://api.github.com/users/disnet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/disnet/subscriptions","organizations_url":"https://api.github.com/users/disnet/orgs","repos_url":"https://api.github.com/users/disnet/repos","events_url":"https://api.github.com/users/disnet/events{/privacy}","received_events_url":"https://api.github.com/users/disnet/received_events","type":"User","site_admin":false},"created_at":"2016-09-06T17:59:39Z","updated_at":"2016-09-06T17:59:39Z","body":"@isiahmeadows we have basic [support implemented](http://sweetjs.org/doc/1.0/tutorial.html#_sweet_modules) for importing a macro along with importing `for syntax`.\r\n\r\nIt's not full support by any means. It's only one phase level (no recursive imports) and only the `import { named }` form is supported.\r\n\r\nI'm currently hacking on it though so full support will be coming Real Soon™️.\r\n\r\n"}}
{"actor":{"display_login":"disnet"}}