Fork me on GitHub

I never submitted the revisions in Andare back to core.async proper because they were fairly “heavy”. There is nothing fundamentally wrong with the changes, and they preserve behavior for non-self-host use. They seems to have withstood the test of time and proven to be reliable. But—it would be a decent volume of code change for the core.async maintainers to decide they are willing to merge in. Since @alexmiller asked, the salient of the changes are in this commit, but it is near impossible to see what they are because of the need to convert to .cljc My overall recollection of the changes was that they largely involved code rearrangement so that macro namespace loading would work properly in self-hosted ClojureScript. If I had to guess, David Nolen would likely be heavily involved in reviewing the changes. I think it would be great if core.async proper targeted self-hosted, but my presumption so far has been that there wouldn’t be enough interest on the part of the core.async maintainers to take on the burden of targeting self-hosted ClojureScript.


@djwhitt Yeah... Andare preserves the public-facing API of core.async, so I suppose it could break code that depends on private core.async internals. If Promesa could depend only on the public API, then Andare could be an optional drop-in for those users that wish to use it in self-hosted ClojureScript.


@mfikes Agreed, that would be best. Unfortunately, Promesa is using the core.async ioc stuff in its own macros:


Well, unfortunate in terms of this dependency issue. It's providing nice functionality with it. 🙂

Alex Miller (Clojure team)01:01:29

well not of that seems objectionable in intent. as you surmised, dnolen would need to be heavily involved in anything like that so I will leave it up to him :)


@djwhitt Also, FWIW, I see no problem with aligning Andare's internals with core.async proper, if it is technically feasible.


@mfikes :thumbsup: I'll explore that a bit.


Something else to explore would be the moving of the IOC macro into the CLJS compiler


A lot of the complexity of the macro could be removed, but that would involve adding a feature to CLJS that doesn’t exit in CLJ