On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote: > > On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge <tbald...@gmail.com > <javascript:>> wrote: > >> I can see that, and even spec has this use case. In Spec it's solved by >> having both A and B in one namespace and using declare to forward-declare >> the constructors (or defns in this case). >> >> So I guess the way I see it the tradeoff is a declare and >> all-in-one-namespace vs a massive complexity addition to the compiler and >> the redefinition of compilation units. The declare method seems like the >> cleaner route. >> >> > I wonder whether there could be something like an `external-declare` that > would satisfy Rich's concerns about knowing how to intern unencountered > vars, while allowing cyclical references when needed. >
The macros defined in ‘scarlett.core’ here: https://github.com/scgilardi/scarlett are an experiment along those lines. *scarlett* Provides macros to declare vars in namespaces other than *ns* To be used sparingly to overcome otherwise cyclic namespace dependencies *Usage* (ns-declare my-module startup shutdown) declares my-module/startup and my-module/shutdown (declare+ module-a/startup module-b/startup) declares module-a/startup and module-b/startup They work by using “declare” after switching to the target namespace using “in-ns” (and switching back at the end). They have to be issued at the “top level” (as is highly recommended for ns, declare, def, etc.) to be effective and they contain code to notify with an exception if they are used at other than the top level. (The exception is preferable to silent failure or a confusing error message.) The macros rely on the compiler behavior of handling top-level “do” forms in a special way: evaluating each of the contained forms sequentially *at the top level*, effectively removing the nesting and allowing each contained form to be compiled and evaluated before compiling the next one. Macro expansion facilities other than the compiler (e.g., in an editor or debugger) may not duplicate that subtle behavior so the expansions they produce may not accurately reflect the expansion that will be produced and seen by the compiler. There may be contexts where that causes trouble at development time. I’m not aware of these being used anywhere in other than experimental/POC code. —Steve -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
