We're updating the issue view to help you get more done. 

Stop using Clojure Namespaces entirely for non-macro names/lookups

Description

AFAICT, the ClojureScript compiler uses clojure.lang.Namespace in only a couple of situations now:

1. during macroexpansion
2. when reading:

  • to bind ns to cljs-ns

  • to set aliases (and their referents) for resolving namespaced keywords/symbols

#1 is unavoidable and unproblematic. #2(b) can cause issues at dev-time though, especially when using portable libraries. For example:

1 2 3 4 5 6 7 (ns simple-check.generators (:require #+clj [clojure.core :as lang] #+cljs [cljs.core :as lang] [cemerick.pprng :as pprng] clojure.string) (:refer-clojure :exclude [int vector list hash-map map keyword char boolean byte bytes sequence]))

The differing lang alias there will always cause an error for the second compiler that attempts to load the file.

A similar problem would also affect any multitenant ClojureScript compilation environment that didn't use classloaders to provide the compiler with its own static clojure.lang.Namespace environment.

A plan:

1. Enhance tools.reader to provide a dynamically rebindable namespaces var (hopefully to contain a map equivalent in structure to the one being used by the analyzer already?).
2. Change the analyzer to:

  • bind that var to the current value of namespaces when reading

  • modify the namespaces map as necessary to account for aliases, etc.

Does this sound sane?

Environment

None

Status

Assignee

Unassigned

Reporter

Chas Emerick

Labels

None

Approval

None

Patch

Code and Test

Priority

Major