[feature] Allow selective macro import #1118
Labels
Comments
|
Yeah, I'm inclined to agree that's a problem. I'm not sure yet of that solution, but it seems reasonable at a glance. I'd like to look deeper at how Hy's macros are implemented, maybe treating them as living in modules isn't appropriate, and something like Clojure namespaces is better. Someone more familiar with that part of Hy's internals might have more to say about it. I'm not sure I'd bother with the deprecation warning at this time, since we're breaking everything for the Grand Language Cleanup anyway. |
Kodiologist
added a commit
to Kodiologist/hy
that referenced
this issue
Oct 27, 2016
You can now do (require foo), (require [foo [a b c]]), (require [foo [*]]), and (require [foo :as bar]). The first and last forms get you macros named foo.a, foo.b, etc. or bar.a, bar.b, etc., respectively. The second form only gets the macros in the list. Implements hylang#1118 and perhaps partly addresses hylang#277. N.B. The new meaning of (require foo) will cause all existing code that uses macros to break. Simply replace these forms with (require [foo [*]]) to get your code working again. There's a bit of a hack involved in the forms (require foo) or (require [foo :as bar]). When you call (foo.a ...) or (bar.a ...), Hy doesn't actually look inside modules. Instead, these (require ...) forms give the macros names that have periods in them, which happens to work fine with the way Hy finds and interprets macro calls.
tuturto
pushed a commit
that referenced
this issue
Nov 3, 2016
Give `require` the same features as `import` You can now do (require foo), (require [foo [a b c]]), (require [foo [*]]), and (require [foo :as bar]). The first and last forms get you macros named foo.a, foo.b, etc. or bar.a, bar.b, etc., respectively. The second form only gets the macros in the list. Implements #1118 and perhaps partly addresses #277. N.B. The new meaning of (require foo) will cause all existing code that uses macros to break. Simply replace these forms with (require [foo [*]]) to get your code working again. There's a bit of a hack involved in the forms (require foo) or (require [foo :as bar]). When you call (foo.a ...) or (bar.a ...), Hy doesn't actually look inside modules. Instead, these (require ...) forms give the macros names that have periods in them, which happens to work fine with the way Hy finds and interprets macro calls. * Make `require` syntax stricter and add tests * Update documentation for `require` * Documentation wording improvements * Allow :as in `require` name lists
|
Closed by 14fddbe |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is related to #277, but (I think) substantially less ambitious.
Right now, the only way macros from another file or module can be included is with
(require foo), which imports all macros defined in the modulefoo. So there are all the usual namespace-pollution perils of(import [foo [*]]):foomight have a macro added to it that happens to have the same name as something in the importing module. The risk of breakage is even greater than withimportbecause ordinarily imported variables can be overwritten by ordinary assignments, whereas macros take precedence over ordinary assignments. Hy doesn't even have a warning for a macro shadowing a function.To fill this gap, I propose a feature that I think will be pretty easy to implement. Analogous to
(import [foo [a b]]), we should allow(require [foo [a b]]), which imports the macrosaandbbut nothing else (and throws an error ifaorbisn't a macro available for import).To make the syntax of
requiremore consistent withimport, we might also make(require [foo [*]])mean what(require foo)currently means, and make(require foo)raise a deprecation warning, so that later we can have it import macros namedfoo.a,foo.b, etc., like(import foo)does for ordinary names.The text was updated successfully, but these errors were encountered: