When launching Planck using plk
, you can specify a vector of source directories in deps.edn
:
{:paths ["src" "test"]}
With this, you can put this code in src/foo/core.cljs
:
(ns foo.core)
(defn square
[x]
(* x x))
Then, if you launch Planck via plk
$ plk
you can then load the code in foo.core
by doing
cljs.user=> (require 'foo.core)
If you subsequently edit src/foo/core.cljs
, say, to define a new function, or to change existing functions, you can reload that code by adding the :reload
flag:
cljs.user=> (require 'foo.core :reload)
Alternatively, when launching Planck you can use the -c
or --classpath
option, or the PLANCK_CLASSPATH
environment variable, to specify a colon-delimited list of source directories and JARs to search in when loading code using require
and require-macros
. You can also use -D
or --dependencies
provide a comma separated list of SYM:VERSION
, indicating libraries to be loaded from the local Maven repository. (See the Dependencies section of this guide.)
Using -c
, you can specify "src"
and "test"
as source directories via
planck -c src:test
If you define macros in bootstrap ClojureScript (which is the mode that Planck runs in), the macros must be written in ClojureScript (as opposed to Clojure, as is done with regular ClojureScript).
Even though the macros are defined in ClojureScript, they are defined in *.clj
files. You can, if you wish, also define macros in *.cljc
files, but when they are processed, the :cljs
branch of reader conditionals will be used.
When writing macros for self-hosted ClojureScript, they must abide the same rules that apply to all ClojureScript code. In particular, this means a macro cannot call another macro defined in the same compilation stage: If a macro calls another macro during expansion, then one approach is to define the called macro in a “higher” namespace (possibly arranged in a tower). On the other hand, if a macro simply expands to a call to another macro defined in the same namespace, then the compilation staging rules are satisfied.
If an exception is thrown, you may see a stack trace. (If not, you can use pst
to print the stack trace for an exception.) When trace lines correspond to code that originated from files, the line numbers are mapped from the executed JavaScript back to the original ClojureScript.
Planck supports tagged literals. For an overview of this feature see the Tagged Literals documentation.
Planck searches for data_readers.cljc
files at the root of the classpath, and the values of the data reader maps are associated with vars that must defined in ClojureScript.
For example, lets say a data_readers.cljc
file contains:
{foo/bar my.project.foo/bar}
Then, in order to parse #foo/bar [1 2 3]
, #'my.project.foo/bar
must be defined in ClojureScript. (This differs from JVM ClojureScript, where this must be defined in Clojure.) This could be accomplished by defining a namespace like the following that is loaded into Planck before expressions involving #foo/bar
are read.
(ns my.project.foo)
(defn bar [x] ,,,)
Note that, in either case (JVM ClojureScript, or self-hosted ClojureScript), the reader function bar
above must return code that is compilable in ClojureScript.
It is possible to make use of the cljs.js
namespace within Planck. But, since Planck is built with the :dump-core
ClojureScript compiler option set to false
, calls to the 0-arity version of cljs.js/empty-state
will produce a state atom which lacks cljs.core
analysis metadata. To produce a populated compiler state atom, you can make use of planck.core/init-empty-state
:
(require 'cljs.js 'planck.core)
(def st (cljs.js/empty-state planck.core/init-empty-state))
(cljs.js/eval-str st "(map inc [1 2 3])" nil
{:eval cljs.js/js-eval :context :expr} identity)
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close