Ken Wesson <kwess...@gmail.com> writes: Hi Ken,
>>> 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. I think, I misused dynamic vars, so let me cite my reply to Meikel: ,---- | Why do I use a dynamic var in the first place? I want to use the | simple names in the *lexical* scope of the `with-schema-imports' | block, and I used a dynamic var only because the resolution takes | place somewhere in the function call tree originating from there. So | a much cleaner solution is to walk the body given to my macro and | replace the simple names with qualified names, so that at runtime | everything is fully qualified. `---- That has the additional advantage that is has no runtime overhead at all. (Ok, the runtime overhead with my current approach was a map lookup, but passing around a resolution context would be a bit more overhead, which is not really justifiable for that basic feature.) Bye, Tassilo -- 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
