The Problem

To proceed to decoupling the clojurescript compiler from its JS backend, we need to have no JS-specific content inside the parse/analyze phases of the compiler.

For the moment, the macro-expansion phase is highly dependent on macros that are js specific. Those macros are defined in the cljs.core namespace (clojure side)

A solution to this problem is to make the namespace in which those macros are defined parametric, and to put the code for each backend in its own namespace (cljs.js.core for js, for example)

The big question is wether the cljs.core namespace on the clojurescript side also needs to be moved in the same namespace (cljs.js.core), or wether it should stay in the cljs.core namespace

It could stay in cljs.core because, at runtime, there is only gonna be one cljs.core. But should it ?

Option 1 : Move everything to a backend specific namespace (namely cljs.js.core)

In this scenario, the current clojure cljs.core, and clojurescript cljs.core would both be renamed to cljs.js.core. Every reference to cljs.core in the compiler would be changed to reference a bound variable containing the name of the core namespace.

Pros

Cons

A solution both those problems would be to alias the namespace automatically to cljs.core

Option 2 : Only move compile-time cljs.core to a backend specific namespace

Pros

Cons

I personnally think the first option is a better option, if there is a way to make the stdlib still exposed as cljs.core in the end, which i think should be possible.


Side problem : How to parametrize

The question is then, how the user would choose which namespace to use ?

Dynamic var works ok, but is not very explicit.

We could use a dynamic var internally, but require the namespace name to be passed explicitly in function parameters for the publically exposed functions ?