> If you were to rewrite those for instance in terms of lists (like you'd probably do in a Scheme) I don't think that that change would be visible to the user f

> If you were to rewrite those for instance in terms of lists (like you'd probably do in a Scheme) I don't think that that change would be visible to the user from pure Clojure code You could probably, but persistent thread-safe data-structures are a bit non-trivial to implement. And I'm not even sure you can build them atop a simple list, and even if you could, definitely they would neither be performant nor memory efficient. I think it would be a cool project to have a kind of Clojure implemented over a more minimal core, like an implementation of the data-structures over a simple array or something, but it also wouldn't really be practical in usage I believe. > This would in principle make adding and then maintaining a new host significantly easier It would, but I wonder if it would just encourage toy implementations. In some ways, now it forces you to re-implement from the get go all the pieces that matter for performance and efficiency. > As for the types, are you speaking about how numbers are Longs/Doubles, and arrays are Java Arrays? And that matches what Java uses - so things work smoother Yup, numbers, strings, regexes, threads, namespaces, they're all host specific. Namespaces are particularly important, you want a Clojure namespace to be a module of the host. Having the same types makes interior a lot smoother, and also it makes implementing Clojure to a new host a lot easier as well, because building custom primitive types over an existing runtime is non-trivial. > but you loose the ability to share libraries which is a shame That's why you've got reader conditionals, so you can still technically implement portable libs, though it does force you to re-implement the parts that differ as the library author. But this is a tradeoff, either reusing the host libraries is trivial and easy, or reusing Clojure's would be. I'd say 90% of the appeal of Clojure on a new host is leveraging the new host's libraries, so I think Clojure makes the right trade off here. And the IO pieces you'd always have to reimplement as well. And because of Clojure generally using interop for that, the person who ports Clojure also has less to re-implement, since users can just use interop. > On the other hand, not having access to all of Clojure's libraries would be a disaster How many of those libs are interop free though? Because otherwise you'd always lose access to them anyways.