Be really careful with Potemkin. I've had a lot of build issues (especially around AOT) with that library. I'll try to put this as kindly as I can...it's a bit of a hack that leverages some undocumented aspects of the Clojure API. As such it's been the source of some really weird compile errors that have taken me many hours to debug. So much so that some libraries have go so far as to copy-paste certain files from potemkin (macros around map-like type creation), in order not to get the more fragile parts of the library (var reorganization).
In short...the language wasn't designed to do what Potemkin tries to make it do when it comes to vars. I really recommend against using the library. On Sat, Dec 31, 2016 at 7:32 AM, squeegee <squee...@mac.com> wrote: > > > 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> >> 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
