This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-16
Channels
- # admin-announcements (2)
- # bangalore-clj (3)
- # beginners (15)
- # boot (303)
- # carry (18)
- # cider (7)
- # cljs-dev (222)
- # cljsrn (103)
- # clojure (196)
- # clojure-czech (2)
- # clojure-russia (69)
- # clojure-spec (21)
- # clojure-uk (48)
- # clojurescript (68)
- # cursive (18)
- # datomic (185)
- # events (1)
- # hoplon (2)
- # lambdaisland (1)
- # leiningen (1)
- # mount (10)
- # off-topic (1)
- # om (14)
- # onyx (154)
- # parinfer (1)
- # pedestal (3)
- # planck (5)
- # protorepl (9)
- # re-frame (17)
- # reagent (27)
- # ring (2)
- # specter (58)
- # test-check (1)
- # testing (7)
- # untangled (59)
- # yada (35)
Clojure got specs for the ns
macro today. Perhaps for ClojureScript there’d need to be compiler-level support for specs on special forms to pull that off. :thinking_face:
just testing v1.9.216 and repl stopped printing warnings when using undeclared vars, e.g. WARNING: Use of undeclared Var cljs.user/abc at line 1 <cljs repl>
https://gist.github.com/darwin/a737a966642f8942cf2c0b09bc22fc20
is this by design?
is it a hard requirement that CLJS sources need to be analyzed/compiled in dependency order?
if yes, why? so that the compiler env has the necessary information from dependents?
@anmonteiro: yes, for the reason you mentioned
@thheller: can you point me towards an example in the codebase?
the compiler populates the env/*compiler*
information (ie. :cljs.analyzer/namespaces
)
@thheller: yea, just found it
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L756
it would break this case, for example
makes total sense, I was kinda expecting that wouldn’t be true though 🙂
caching just writes the analyzer information to disk so it can skip the compilation on the next go
@anmonteiro: any particular reason you were interested in the answer?
@dnolen: looking at this: http://dev.clojure.org/jira/browse/CLJS-1346
I thought it would be a very useful addition
was trying to figure out where to hook up loading dependencies that are not part of the ns
form
@anmonteiro: that ticket is far less ambitious than it sounds
@dnolen: hrm, it seems that it would be easier to make it work if it only appeared at the beginning
I was going for require
at arbitrary sources, and currently thinking of an approach like you did with preloads
where we’d hook up the missing dependencies there, and reorder sources again
@dnolen: yep, I think I understood that by the description.
so in that case would require
be a special form?
that’s part of the reason why I was going for the extra mile
having macros in cljs.core
and supporting require
at arbitrary locations would probably solve the other cases
or am I missing something?
by macros in cljs.core
I mean require
, require-macros
, etc defined in cljs.core
what would the code reshaping be in this case?
@dnolen: does an approach like I described earlier qualify as “really complicated ways”?
as in, save missing requires in the compiler env when we first process inputs
and add those to the sources later when we have expanded the eventual require
s
OK that makes sense to me, but I don’t understand why that would be deferring loading
My idea was to have a require
macro that when expanded during analysis would side-effect the compiler env
so this would not be deferring
allowing require to appear in random places if you can’t support this stuff isn’t really useful since too many broken expecations
@dnolen: I got it now
I don’t like the idea of introducing 5 new special forms, though
or is that not a problem?
require
, use
, refer-clojure
, require-macros
, use-macros
would have to be supported, I believe
@thheller: because lots of perfectly code fine is written without relying on it’s full power
people have been asking for a way to do something like this since pretty much the beginning of ClojureScript
@thheller: my main motivation for giving a look at this ticket was to have support for extensible tagged literals down the road
in cljs require
would need to do an async fetch since you can't do blocking IO in the browser
I fail to see how require
(if restricted to top level) is any different from putting it in the ns
I still don’t see what this has to do what @anmonteiro and I were discussing
so I assumed you were talking about being able to do (require 'some.thing)
as in clojure
yeah, just saying that given the constraints of a browser it cannot work unless I'm completely missing something
ah well you basically made the exact same points I was aiming for .. slack didn't show the complete history .. sorry for the noise
@thheller: @dnolen if I understand well, GClosure requires in CLJS are static (compile-time), right? So a static, compile-time require
could be made to work in arbitrary parts of a file, if I understand correctly
Does this imply, however, broken semantics?
Was this that you were referring to as broken semantics?
@anmonteiro: we need to be clear about Clojure semantics vs. what ClojureScript supports
Right
I think I'm not explaining myself well enough as to what I want to achieve
we also want to support a small but important set of Clojure programs that use require
@dnolen: my intentions with this patch would be to support require
at the top-level, but not at arbitrary locations of a file (e.g. inside functions)
I think this can be made to work
and IMO would be probably better than a require
special form
it would obviously not have the same semantics as in Clojure
e.g. things like this would work:
(ns cljs.require-test
"Tests require support outside of the ns form")
(require '[clojure.test :refer [deftest is] :rename {is is?}]
'[cljs.spec :as s :refer [spec? spec] :rename {spec foo}])
then again, not sure if desirable or not, also why I need this discussion to be clarified
you’re suggesting something which requires more explanation about cases that don’t work
pretty sure they would work
@anmonteiro: they won't
@dnolen: that may be the case.
But by making this require
static, as if the require
were in the NS form, wouldn’t it work?
this is what I was thinking about all along
which I why I wanted to insert it in the build pipeline
since it doesn’t trigger loads
we’d have to load the dependencies for them
I’ll make sure to re-read the conversation history to get the full picture
@dnolen: but I don’t think I understand what you mean by the expectations about side-effects
@anmonteiro: I also do not understand your example above
my example above is supposed to be equivalent to having the :require
in the NS form
no it’s not solving any problem by itself
but wouldn’t it allow the NS form not to be mandatory then?
you want to solve a wider problem - but I’m having difficulty seeing see how it doesn’t bring in a lot of orthogonal issues along for the ride
yea, that sounds about right
another problem is that I’m failing to see what orthogonal issues my solution would imply
@anmonteiro: what actual good is the increased flexibility buying you here?
(I do understand that the semantics would be slightly different from Clojure’s)
but a lot of things in Clojurescript are different because of its compilation model
@dnolen: I think I’m arriving to an understanding. Having the increased flexibility of putting require
wherever at the top level just doesn’t do anything besides just that, which is not good enough by itself
gotcha. everything would still be static because of goog.require
I had already understood that
@dnolen: OK thanks so much for taking the time to clarify all of this. I’ll pursue the special form approach
@anmonteiro: re side-effect problems
(require ‘[foo.core]) (def x foo.core/y) (set! foo.core/y 5) (require ‘[foo.util]) (def z foo.core/y)
@dnolen: in that case I suppose CLJS would only be able to require
foo.core
once
right
so limiting user options will ensure correct behavior
I can understand that
@dnolen: then again, doesn’t having support for require
outside of NS imply that we can do what I did in my example above?
@anmonteiro: perhaps for the case where require appears right after the ns form, but this isn’t something we need to advertise or anything
@dnolen: I imagine parse-ns
needs to support both for multiple requires/uses to be additive
@anmonteiro: maybe, but maybe not
this ticket is tricky enough where it might be useful to write out a plan in the comments first
sounds good, I’ll do that
@dnolen: I’ve added some initial thoughts to the ticket http://dev.clojure.org/jira/browse/CLJS-1346?focusedCommentId=43571#comment-43571
I’m probably missing some things that will only become clear after your feedback
@anmonteiro: thanks! will provide feedback later today, tomorrow morning at the latest
yeah, no rush