Clojurians
#cljs-dev
<
2015-12-02
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

mikethompson00:12:06

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: http://www.infoq.com/news/2013/04/tracegl (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.

mikethompson00:12:14

(Something like https://github.com/spellhouse/clairvoyant is currently the poor mans version of what I'm talking about)

mikethompson00:12:24

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.

mikethompson00:12:45

Anyway, just a thought

dnolen00:12:06

stuff like that is just outside core development

dnolen00:12:16

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

dnolen00:12:27

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

mikethompson00:12:30

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

mikethompson00:12:50

Its almost like plugins at various points

dnolen00:12:26

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

dnolen00:12:52

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

dnolen00:12:36

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

kamn04:12:14

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?

nullptr05:12:02

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 http://dev.clojure.org/jira/browse/CLJS-1402 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

r0man08:12:23

Thanks, for the release @dnolen.

dnolen12:12:20

@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.

dnolen12:12:54

@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

dnolen12:12:21

@r0man: np

dnolen12:12:10

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

thheller12:12:51

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

dnolen12:12:58

@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.

dnolen12:12:38

@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.

dnolen12:12:54

so somebody would have to fix that problem first

dnolen12:12:48

@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

dnolen12:12:10

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

dnolen12:12:00

might be a wash for us of course

dnolen12:12:23

Scala code tends to be outrageously large

thheller12:12:53

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

thheller12:12:00

the analyzer based rewrite

dnolen12:12:23

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

dnolen12:12:38

somebody should just do that

thheller12:12:53

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

thheller12:12:10

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

thheller12:12:15

where it doesn't have to

dnolen13:12:08

heh that too