This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-20
Channels
- # architecture (25)
- # beginners (68)
- # cider (10)
- # clara (3)
- # cljs-dev (90)
- # cljsrn (16)
- # clojure (132)
- # clojure-austin (7)
- # clojure-berlin (3)
- # clojure-czech (1)
- # clojure-dusseldorf (1)
- # clojure-greece (5)
- # clojure-italy (39)
- # clojure-spec (5)
- # clojure-uk (78)
- # clojured (2)
- # clojurescript (92)
- # community-development (6)
- # cursive (7)
- # data-science (1)
- # datascript (14)
- # datomic (32)
- # duct (8)
- # emacs (5)
- # figwheel (3)
- # fulcro (47)
- # hoplon (12)
- # jobs (10)
- # luminus (16)
- # lumo (5)
- # off-topic (1)
- # onyx (2)
- # parinfer (47)
- # pedestal (6)
- # re-frame (10)
- # reagent (2)
- # reitit (61)
- # ring (8)
- # ring-swagger (16)
- # shadow-cljs (116)
- # sql (17)
- # utah-clojurians (2)
- # vim (1)
@richiardiandrea Unit tests failing with the last commit https://github.com/mfikes/clojurescript/commits/master
It is script/test-self-host
^ https://dev.clojure.org/jira/browse/CLJS-2539
Thanks Mike!
I want a reader literal which expands to cljs code that needs some imports to work. Is this possible without manually requiring the necessary imports in every ns the literal is used in?
why questionable? It's not a problem in clj because the ns that implements the data reader does the require; it's only a problem because of the tiered compilation
I guess I just don’t know why you want to do that, data literals that require anything more than the reader tag fn just seems like a bad idea
I don’t use spy, but I dunno. I wouldn’t do this. Perhaps for ClojureScript it’s better for UUID to be overrideable since there’s no standard JS thing for that unlike Java
Tag as a shorthand literal for creating a type would be impossible; but if it's not a standard type you can live with macros
because compile and runtime are same process, reader fn can return the type instance directly
in cljs, often you need to emit something that will be evaluated later; this is where the require problem comes in
actually it looks like the form returned from a reader fn is expanded in the ns of the reader fn?
otherwise I'm not sure how this would work: https://github.com/dgrnbrg/spyscope/blob/fa081d72f916e81d269203ad5c5449b8389e0ff8/src/spyscope/core.clj#L66-L69
the pp
alias at least needs to be expanded; but you do need to inject (require 'spyscope.core)
into your repl to make sure puget.printer
is available.
so the same technique would probably work in cljs: make sure you inject the requires/imports your readers need at the top of your code before building
there's just a class of problems that doesn't arise in clojure because the reader can return an instance
you cannot return instances, but you return whatever you want from the Clojure side to be interpreted as ClojureScript
so then I don’t understand the problem, you just can’t return instances, but that’s not an issue for the record use case for example
but the emitted clojurescript still needs a require; this happens much less often in clj because it can just return the instance
myfoons.clj contains (ns myfoons (:require bar)) (defn foo-reader [x] (bar/make-bar x))
in this case the type is constructed at read time; bar is required by clojure loading myfoons to invoke the data reader fn
yes, but clj can use that loading to make the type and return it directly; cljs needs an additional runtime load most of the time because the type cannot be constructed in clj
All I'm saying is it doesn't come up as much because clj can just make things that cljs would have to emit code to make later
in both clj and cljs you have to inject the require somewhere at the top of your codebase so this works
you just want to know it will be present so it will work - one possible solution - we could make data reader nses implicit and higher in the dep chain
so proposal is: require nses mentioned by data_reader.cljc and data_reader.cljs in the cljs compilation stage of non-self-host
so I would suggest fixing this in the build pipeline i.e. cljs.closure
, no need to change anything else
@favila even if you don’t feel like taking it on feel free to submit an enhancement ticket with the proposed solution
on the subject of requiring at runtime, how do you plan on handling this resolve-fn
case for the prepl port? https://github.com/clojure/clojure/blob/86a158d0e0718f5c93f9f2bb71e26bc794e7d58e/src/clj/clojure/core/server.clj#L252