This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-02
Channels
- # admin-announcements (29)
- # aws (11)
- # beginners (247)
- # boot (11)
- # business (1)
- # cider (73)
- # clara (5)
- # cljs-dev (37)
- # cljsrn (29)
- # clojure (86)
- # clojure-dev (9)
- # clojure-indonesia (1)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-russia (195)
- # clojure-sg (2)
- # clojure-uk (3)
- # clojurecup (1)
- # clojurescript (296)
- # clojurex (2)
- # code-reviews (6)
- # core-async (3)
- # cursive (33)
- # datavis (9)
- # datomic (11)
- # funcool (31)
- # hoplon (1)
- # ldnclj (8)
- # lein-figwheel (5)
- # leiningen (5)
- # luminus (4)
- # off-topic (3)
- # om (172)
- # onyx (13)
- # re-frame (5)
- # reagent (84)
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.
(Something like https://github.com/spellhouse/clairvoyant 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
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
Fair enough
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 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
@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.
@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