{"action":"closed","issue":{"url":"https://api.github.com/repos/anko/eslisp/issues/27","labels_url":"https://api.github.com/repos/anko/eslisp/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/anko/eslisp/issues/27/comments","events_url":"https://api.github.com/repos/anko/eslisp/issues/27/events","html_url":"https://github.com/anko/eslisp/issues/27","id":110731738,"number":27,"title":"User-macro calls given as user macro arguments always compile to function calls","user":{"login":"anko","id":5231746,"avatar_url":"https://avatars.githubusercontent.com/u/5231746?v=3","gravatar_id":"","url":"https://api.github.com/users/anko","html_url":"https://github.com/anko","followers_url":"https://api.github.com/users/anko/followers","following_url":"https://api.github.com/users/anko/following{/other_user}","gists_url":"https://api.github.com/users/anko/gists{/gist_id}","starred_url":"https://api.github.com/users/anko/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/anko/subscriptions","organizations_url":"https://api.github.com/users/anko/orgs","repos_url":"https://api.github.com/users/anko/repos","events_url":"https://api.github.com/users/anko/events{/privacy}","received_events_url":"https://api.github.com/users/anko/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/anko/eslisp/labels/bug","name":"bug","color":"fc2929"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-10-09T20:36:38Z","updated_at":"2015-11-11T15:55:38Z","closed_at":"2015-11-11T15:55:38Z","body":"As @stasm [mentions](https://github.com/anko/eslisp-fancy-function/issues/1#issuecomment-145901313) in anko/eslisp-fancy-function#1, if a call to a user-defined macro is given as a parameter of another user-defined macro, it always compiles to a function call, not to the results of that macro.\r\n\r\nExample:\r\n\r\n```\r\n(macro fun0 (lambda (body)\r\n  (return `(lambda () ,body))))\r\n(macro ok (lambda ()\r\n  (return '(return true))))\r\n(fun0 (ok))\r\n```\r\n\r\nExpected output:\r\n\r\n```\r\n(function () {\r\n    return true;\r\n});\r\n```\r\n\r\nActual output:\r\n\r\n```\r\n(function () {\r\n    ok();\r\n});\r\n```\r\n\r\n- - -\r\n\r\nThis does not affect built-in macros, because they can access the [compilation environment](https://github.com/anko/eslisp/blob/master/src/env.ls) with which they can optionally compile their arguments (for example [like this](https://github.com/anko/eslisp/blob/064b8b2e6b746c2cdf9868b11bc20cdd873d4a40/src/built-in-macros.ls#L170)) in a way that resolves and executes macros.\r\n\r\nUser macros currently don't have that choice. They operate on lists they've received as arguments, but the process by which they're compiled doesn't take macros into account. If it did, we'd have the opposite problem. There needs to be a user choice.\r\n\r\nTo give an example, if `a` is a user-defined macro and it is called with `(a (b))`, it receives 1 argument, which is an array containing an atom `b`. If it returns that argument as-is, it is interpreted as a function call `b();`, which the macro may have wanted to return. But another interpretation is to compile the list *taking the macro table into account*, in which case it may turn out that `b` is a macro that returns different code to be used there instead.\r\n\r\n- - -\r\n\r\nThere obviously should be no such limitation. I could use some help from more experienced lispers here. What would Batman do? Is this what [`macroexpand`/`macroexpand-all`](http://www.gnu.org/software/emacs/manual/html_node/elisp/Expansion.html) are for?"}}