On Sun, Mar 20, 2011 at 5:41 PM, Tassilo Horn <tass...@member.fsf.org> wrote: > Ken Wesson <kwess...@gmail.com> writes: > > Hi Ken, > >>>> Does the resolving function run on, or use, another thread? >>> >>> No, it runs in the same thread. But some functions like `vseq' in >>> the example produce LazySeqs. So if LazySeq-realization computations >>> are run in a different thread by default, that would explain things. >> >> They're not, but if the LazySeq realization is not happening until >> after the scope of your with-schema-imports is exited, it would >> explain a thing or two. You may need to sprinkle some doalls about. > > Oh, yes. That was the exact issue. But clearly forcing realization is > not a good solution. Is there some better way to do what I want? > Maybe my macro should expand to something like that? > > ((fn [] (binding [...as before...] body)))
Still won't work if unrealized lazy seqs are returned from the function. I think what you want is to pass a kind of resolution-context object as far as the resolve calls. The lazy seq elements will close over this object and the resolver will use it. The macro would become sugar for making the object without a lot of messy quoting, something like (let-schema-imports [sis [localities.Locality]] (do-something parm1 parm2 sis) ...) (defn do-something [parm1 parm2 sis] (make-lazy-seq-of-some-sort ...)) ... (defn something-else [x y z sis] (act-on x (resolver-macro-of-some-sort sis Locality) y z) ...) Of course, explicitly passing sis around everywhere might also get annoying. The only alternative to that and eagerly realizing your seqs is a static set of name imports with either global or lexical scope. Actually, you might want to try writing a macro that will take localities.Locality and emit a defmacro that will cause (Locality) to expand to localities.Locality, then use (Locality) wherever you presently use Locality. This gives you namespace scoped imports, in effect: you use the defmacro-emitting import macro at the top of a sourcefile and (Locality) elsewhere in it, and (Locality) refers to localities.Locality throughout that source file (and nowhere else if you don't want it to). And there's no run-time overhead for any of it either. -- 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
