wat ? that is very cool

You could also use with-redefs to temporarily disable these functions maybe

as a crude workaround

it doesn't work for inlined functions though:

(with-redefs [inc nil] (inc 1))

but that should be an acceptable edge case

I’d like for the rest of the tests to still work, but if I can’t have that, then maybe redefs is the way to go…

what rest of the tests?

I mean, evaluate the answer in the with-redefs, not all of your project

@U0ETXRFEW do you use a separate namespace for each problem?

Then you could also use :refer-clojure :exclude [the-forbidden-var] perhaps

of course users can hack around this, but who are they fooling but themselves

For a problem like: > Write a function which returns the last element in a sequence. Which restricts the use of last. And the tests:

(tests
 (__ [1 2 3 4 5]) := 5
 (__ '(5 4 3)) := 3
 (__ ["b" "c" "d"]) := "d")

(def __ last)

(tests
 __ :<> last
 (__ [1 2 3 4 5]) := 5
 (__ '(5 4 3)) := 3
 (__ ["b" "c" "d"]) := "d")

> do you use a separate namespace for each problem Yes

yes, so you could use :refer-clojure :exclude [...] then?

with ... containing only the restricted var per problem

That would make the tests in the example with

(def __ last)

You have said this before but I didn’t understand what you said. Isn’t the whole point to make this fail because that specific var is forbidden?

SCI supports evaluating expressions while forbidding certain symbols/vars

You could also use normal JVM eval while pre-processing the sexpr

It can be argued what the point is. 😀 I want the user to be able to freely explore. Also the restricted things. I am fine with not checking it at all, but one of the first users seemed to get confused by that. So want to investigate what it could take. And learn something in the process.

So you want to both allow and disallow it? Yeah I can see how that can be a conflicting requirement :-)

But again, I think with-redefs or some light macro around this called forbid or so, could work

So you can locally forbid it

Haha, yeah, conflicting requirements. I’m thinking more like clj-kondo, it gives advice, but doesn’t force you do to anything. Maybe it could even be implemented as a linter? That would be great!

@U055NJ5CC also asked for a similar thing, if he could somehow emit extra lint warnings so clj-kondo would display them (I think?)

clj-kondo could support this e.g. by having a directory in .clj-kondo where people can dump extra findings in an EDN file, clj-kondo would return them on the next run or so

but then you would only see them on the next edit. and the tool should then also take care to remove the findings when the error was no longer there

perhaps CIDER supports something similar

a findings-file would be great. Or a socket endpoint in LSP-server to receive edn-events. In my use-case, I know a Var and would like to tag an issue for it, e.g.

{:var user/kikka
 :level :warning
 :message "invalid function schema, calling function with arguments (0, 0) produces invalid output \"00\", should be :int"}

for clj-kondo running as a non-server (standalone binary) a socket won't work, I think the only way would be a file

for clojure-lsp a directory watcher or so could work

but let's say for the sake of argument, we went with the file option

what would be the flow?

user in a REPL activates your tool, tool finds something, emits a file

then clj-kondo has to run, but the editor tooling only makes it run on the next code edit

so there is a synchronization problem there

yes. It already recreates the full clj-kondo config per each check (which happens when user evaluates a form, via atom watcher)

I think something in CIDER could be more appropriate since it's really something that comes from the runtime. I'm surprised that people have made specific tooling for flycheck when it comes to eastwood linting since that could probably also be implemented as a CIDER middleware? E.g here is some code to display stack traces. https://github.com/clojure-emacs/cider-nrepl/blob/6d3934eb665574af891e81ef5c11cf9c2b4e1d65/src/cider/nrepl/middleware/stacktrace.clj#L197

@U051BLM8F any thoughts?

Yeah, that should be easy to do.