Current-namespace keywords always resolved to 'user #72

Closed
cemerick opened this Issue Feb 12, 2013 · 2 comments

Comments

Projects
None yet
2 participants
Contributor

cemerick commented Feb 12, 2013

e.g. ::foo always is always read as :user/foo, even if it is within the scope of another namespace.

This is related to gh-14 insofar as reading these keywords as expected requires support of the runtime; however, unlike that issue, we shouldn't need to load any code to obtain correct results. We just need to know when in the load process *ns* would change. I've been experimenting with this reworking of kibit.check/read-file with good results:

(defn read-file
     "Generate a lazy sequence of top level forms from a
   LineNumberingPushbackReader"
     [^LineNumberingPushbackReader r]
     (let [ns (atom *ns*)
           do-read (fn do-read []
                     (lazy-seq
                       (let [form (binding [*ns* @ns]
                                    (read r false eof))
                             [ns? new-ns k] (when (sequential? form) form)]
                         (when (and (symbol? new-ns)
                                 (or (= ns? 'ns) (= ns? 'in-ns)))
                           (reset! ns (create-ns new-ns)))
                         (when-not (= form eof)
                           (cons form (do-read))))))]
       (do-read)))

This works for the check-reader and check-file cases when an ns form is present, but will fail on check-expr unless the expression in question is from 'user. To be complete, all three should probably accept a new :ns option to specify what the initial reading namespace should be.

Thoughts?

Owner

jonase commented Feb 13, 2013

I was previously on the verge to do code-loading but that would probably not be a good fit for cljx (or clojurescript, if I ever get time to do kibit for cljs).

AFAIK your approach shouldn't impact the kibit plugin at all so if this version of read-file is useful for cljx then I'll happily accept a pull request.

Contributor

cemerick commented Feb 13, 2013

Yeah, loading code would probably lead to all sorts of nasties.

There are only a couple of forms that are relevant to this and gh-14, and we should be able to statically maintain *ns* and an accurate map of aliases, modulo e.g. macros that emit in-ns, non-top-level ns or require forms, etc.

I'm in the process of attempting to drag a Clojure codebase into being ClojureScript-portable via cljx, so I'll see what I can put together w.r.t. a more complete approach along the way, suitable for a PR.

cemerick added a commit to cemerick/kibit that referenced this issue Feb 13, 2013

@jonase jonase closed this in a0a7539 Feb 14, 2013

jonase added a commit that referenced this issue Feb 14, 2013

Merge pull request #73 from cemerick/master
"statically" maintain *ns* to yield proper namespacing of ::keywords, fixes gh-72
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment