This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-12
Channels
- # adventofcode (1)
- # announcements (1)
- # atom-editor (4)
- # aws (4)
- # babashka (7)
- # beginners (46)
- # biff (14)
- # calva (11)
- # cljdoc (2)
- # clojure (78)
- # clojure-art (1)
- # clojure-austin (1)
- # clojure-europe (50)
- # clojure-nl (2)
- # clojure-norway (22)
- # clojure-spec (2)
- # clojure-uk (2)
- # clojurescript (72)
- # conjure (6)
- # core-typed (6)
- # eastwood (4)
- # events (1)
- # figwheel-main (11)
- # fulcro (1)
- # guix (1)
- # helix (13)
- # jobs (2)
- # jobs-discuss (4)
- # kaocha (2)
- # malli (5)
- # off-topic (7)
- # pathom (22)
- # pedestal (9)
- # re-frame (29)
- # reagent (7)
- # releases (2)
- # remote-jobs (1)
- # rewrite-clj (12)
- # shadow-cljs (44)
- # sql (13)
- # squint (2)
- # xtdb (17)
I'm currently thinking about how I can implement a REPL based on es6 dynamic import. It's quite painful...
What I currently do is write the expression to a file .repl/foo.js
, then dynamically import that file. But you get back a module. If the expression is (+ 1 2 3)
it gets compiled as 1 + 2 + 3
. But if you evaluate foo.js
you don't get 6, or an object with 6, just a module that contains exports (and just 1 + 2 + 3
doesn't export anything).
So right now I'm wrapping the expression in var _repl = 1 + 2 + 3; export _repl
. But this won't work for (defn foo [])
since that compiles as var foo = function ....
so wrapping it naively in var _repl = foo = function () ....
. Bummer. So maybe every compilation unit should be handled specially for REPL usage. Which is quite annoying!