It would be cool if nrepl had a customizable Eval like clojure main does

@dominicm is this related to babashka somehow or just a general remark?

The babashka eval could be hooked up to nrepl then for most tooling to just work

@dominicm make a middleware that intercepts eval messages, that's basically what piggieback does

slightly less trivial than it sounds because nrepl middleware is confusing as heck, but at least in theory fairly straightforward

is there a tutorial on cider / nrepl middleware? this topic also has come up in clj-kondo: maybe it's possible to have a middleware which lints your project and then emits feedback like unused vars.

so it seems useful to know at least some basics about it

@borkdude I think that my blog post has a lot of internal detail. But the examples in the source of nrepl are pretty good.

which blog post?

https://lambdaisland.com/guides/clojure-repls/clojure-repls#org21653fa

https://juxt.pro/blog/posts/nrepl.html

nice, thanks

What do you think about the following? in babashka / sci everything that is def'ed is effectively treated as a constant. it's even a little bit more strict than direct linking in clojure. so (def ^:const x 1) (defn foo [] x) (def x 2) (foo) will return 1 in Clojure but: (def x 1) (defn foo [] x) (def x 2) (foo) will return 2 in Clojure, but 1 in babashka. I'm now implementing real vars, so you can opt out of this:

$ bb '(def ^:redef x 10)
(defn foo [] x)
(def x 11)
(foo)'

also, there will be "real" dynamic vars:

$ bb '(def ^:dynamic *foo* 1) (binding [*foo* 2] (prn *foo*)) *foo*'
2
1

my vote is to make redef default without the annotation -- i think it will be less confusing

iiuc, the number of current users is not enormous

i presume porting code would be facilitated if behavior is closer to clojure's

cool about the dynamic vars

definitely want them 🙂

yeah, it wasn't a very conscious decision to make it behave like ^:const, I think it was more driven by the absence of real vars so far

we can still have direct linking + ^:const

there is a var branch in babashka and sci where I'm developing this, in case you want to try it out. I agree with sogaiu that we should probably be as close to clojure as possible

the CLJS version of sci is even closer to JVM clojure than CLJS is in this respect:

(require '[sci.core :as sci])
(println (sci/eval-string "(def ^:dynamic x) (set! x 10)")) ;; Can't change/establish root binding of #'x with set

i guess you are working on binding

yes: https://clojurians.slack.com/archives/CLX41ASCS/p1575325153484300

hmm, i asked because when i tried in sci, i got:

(print (sci/eval-string "(def ^:dynamic x) (binding [x 2] (set! x 10) (print x))"))
nilnil

so i presume it is "in-progress"

or may be i screwed up or misunderstand 🙂

try `(sci/with-out-str (sci/eval-string ..))'

by default the out stream is bound to a Writer to not mess with the outside world

oh, great it seems to work 🙂

but you can bring in the normal in and out by using the {:out *out*} option, then you will bind the internal *out* dynamic var to the external *out* value

so (sci/eval-string "..." {:out **out*})*

or you can just bring in the external print using {:namespaces {'clojure.core {'print print}}} , these are your options now

thanks -- just tried the options map with :out -- worked fine

this decision is based on not mutating the world when evaluating sci expressions, unless the sci library user gives permission for this

in the babashka var branch you can see that :in and :out are used

also the :namespaces approach worked too sounds like there is some kind of jail functionality

there is also (sci/with-bindings {sci/*in* *in* sci/*out* *out*} (sci/eval-string ...))

maybe I should deprecate the :in and :out options in favor of the latter

that worked here too 🙂

I will copy paste this conversation and distill some docs out of this

docs via socratic dialogue...or would that be slackratic dialogue?

haha

like the little schemer, etc

The issue is here btw: https://github.com/borkdude/sci/issues/175

I'm pretty excited that sci now gets "real" vars with thread-local bindings

i am too -- i have something i'm hoping will work in bb before too long

you can tell me what it is later, but it's sleepy time here

bye bye

and thanks for testing!