Fork me on GitHub

There was a question in here a little while back about "what next", and I wanted to offer a thought (even though I have no right to have much of an opinion, given I don't currently contribute to core) .... Here's the area where I think clojurescript currently doesn't make the most of itself: tracing. There's a potentially MAGNIFICENT tracing story just waiting to come out. (And an associated magnificent debugging story) I'm talking about the potential for something like: (only much better) The difficulty with tracing clojruescript has been macros. But in this regard, Colin Flemming, has recently shown the way in his latest Conj talk on how he deals with macros.


(Something like is currently the poor mans version of what I'm talking about)


Given all the considerable advances in tooling over the last year, and given Colin's insights, it felt like maybe the huge wow factor associated with tracing might be achievable now.


Anyway, just a thought


stuff like that is just outside core development


but nothing should stop anyone from say hooking into the analyzer and working on that


we added multiple pass support a long time ago for things like this


Yes, I was under the impession that hooking into the pipeline was going to be necessary


Its almost like plugins at various points


there’s also tools.analyzer.js that probably needs more pushing along from the community


so from the core the interest is to support this kind of work, but not necessarily pursue any particular avenue


I’d say what we have in the pipeline already that I mentioned is enough to keep us busy for the next year


I had a question about the "whats next" for CLJS based on @nullptr talk. What about types? Is that outside the core language and for core.typed to resolve? There are some storied for using Closure's type system but is that for the compiler only?


kamn: currently you can make use of google closure type checking by enabling some compiler flags and adding metadata, main issue is that the errors don’t get source mapped — from there, could do a decent amount w/o core.typed -- i have flagged, will try to take a look at that when i get some time — once that’s fixed i think there’s a story to tell


Thanks, for the release @dnolen.


@kamn there’s some initial work for just leveraging Google Closure’s type checker I started but it’s going to require someone to dig in to take it to the finish line. More than happy to point somebody along the path, I’m too busy to wrap it up myself.


@kamn the other related thing would be better type propagation and using conditionals to propagate type information for checking purposes as well as optimization a la Typed Racket / Typed Clojure


@kamn: and @nullptr is correct about source mapped error logging, this has a bunch of benefits - more sensible type errors being one of them


is tools.analyzer.js still on the agenda? ie. migrating cljs.analyzer or are they more likely to stay independent?


@kamn another thing to investigate is just how this stuff works in Google Closure itself and whether it might be feasible to make it more extensible in some way.


@thheller: it could be on the agenda but as it is right now tools.analyzer.js is 4-5X slower than what we have which is unacceptable.


so somebody would have to fix that problem first


@thheller: besides AST unification which would be great, when/if that lands, it would a good time to see if we can do our own simple dead code elimination pass before Closure


this is what Scala.js does and it’s a huge perf boost for the final advanced compilation bit


might be a wash for us of course


Scala code tends to be outrageously large


yeah I'm more interested in porting the clojure core.async bits into cljs


the analyzer based rewrite


@thheller: yes, though that probably doesn’t need to wait for AST unification


somebody should just do that


don't have enough time at the moment but it is on my list


since cljs.core.async sometimes generated absurds amounts of code


where it doesn't have to


heh that too