That's a great resource!

https://github.com/binaryage/dirac/blob/master/docs/about-repls.md

most likely declare but yeah that's pretty much the same

Every time I get unbound I realize that the specific code with the var doesn’t run .. so the def is never set .. but yours might be a different scenario

this is the case - I checked

Thank you for doing that! I guess one thing that in no-small-part made me think way is nil-punning. Python for example, throws KeyError instead of just returning None.

True, nil-punning means that a lot of times you don't need to check for/exclude nil arguments (which is a win, in my opinion).

Do you mean you want to pass a string to C code that contains the two character % followed by n ?

Neither of those should require special escaping that I can think of.

yes exactly

but it will go to printf and it interprets things some way

C code libraries often expect strings to be 8-bit, not 16-bit as they are in Clojure/Java, but I don't know what JNA might have in the way of translation of string contents there.

Well, 16-bit as they are in Clojure/Java, except when they are restricted to the ASCII subset, then JDK 9 and later will actually store them as 8-bit.

Oh, you want the C printf to get a format string such that it will output % followed by n ?

like here https://github.com/runejuhl/clj-journal/commit/15b78e7f4c691bb61df18ce8814a2db087462ac4#commitcomment-37062267 it crashes, but the author escapes things with adding _ betwean those symbols

Then typically you escape the % using %%

yes - I fust want to use printf and print the %n

If you want C printf to print out %n you should be able to do printf("%%n")

thank you!

That happens on every CI build as a way of linting a corpus for checking regressions. Why you ask?

Just curious if you had done it. At least tools.analyzer.jvm that Eastwood uses, that was a big step making that not give any errors running on most/all clojure.core code.

yeah. I used a lot of false positives from clojure itself to improve clj-kondo in the beginning

In particular, one line of code in the Clojure.data namespace might cause that warning on the use of union you showed to fire.

https://github.com/clojure/clojure/blob/master/src/clj/clojure/data.clj#L118

Yeah, I think that also came up when speculative got specs for clojure.set: https://github.com/borkdude/speculative/issues/70#issuecomment-435185067

and now that I remember some discussions on speculative, I probably sound like a broken record there 🙂

it seems clj-kondo doesn't catch that error, maybe because it has no type annotation for keys yet.. I'll check

I don't mind some repetition of interesting facts 😉

ah, it has, but the return type is :seqable . clj-kondo has a somewhat relaxed type system, so when something can take the form of some valid input it doesn't complain. and keys can return nil which would be a valid input for set/union

I could change the return type to :seq and then it would work

although it wouldn't be entirely accurate...

I guess it depends on whether you avoid a warning when something might be given valid input, vs. when it must be given valid input

if you take the first route then you end up changing your code just to avoid type warnings

sorry, the second route

I know small changes to conditions for issuing warnings can change false positive rates in unexpected ways, until you try it on many code bases, sometimes.

it's kind of what you get with typescript where you must convince the compiler that some object has a certain key

you end up writing more code to make the system happy

understood.

but in practice, changing the return type of keys to :seq might not be that bad.

for the purpose of linting that probably just works fine

I'll try it and make a diff

works and no other regressions: https://github.com/borkdude/clj-kondo/runs/419883444 expand the diff thing

< clojure/data.cljs:52:39: warning: Expected: set or nil, received: seq.
< clojure/data.cljs:52:48: warning: Expected: set or nil, received: seq.

hmm, only .cljs though, that's a bit funny...

oh I see, clj-kondo skips over extend-protocol

But keys can return nil or seq

So isn't a return type of seq wrong?

yeah, it's wrong, but for the purpose of linting it's probably fine

the nil is the bit that breaks the type checking

It might be better to warn if nil is passed to keys, then if it returns nil ?

I feel the latter might give an error somewhere else and be more confusing no ?

But I don't know, keys on an empty map seems common to me

And I use keys often with map for example. So the nil punning seems really useful, so that if the map is empty then I don't need to loop over anything

an empty map is not the same as nil

(keys {}) returns nil

That's why I'm saying if the linting was changed to check that nil isn't passed as input to keys, but the return type still allowed nil

@U0K064KQV Can you come up with a practical example where a return type of keys being spec-ed as seq instead of seqable results in a linter warning?

I mean real code, not words

Relying on keys returning nil might even be relying on an implementation detail, since it's not even in the docstring

No, I'm just thinking through this, no real example

And, now that I think some more, I wasn't really thinking type checking but return type validation. In a type check scenario, I think you're probably right

yeah, it's statically checked where this probably works out

A fucntion that takes seqable, if passed a seq, that's valid correct?

yes

Ya, so I guess all the scenarios I'm thinking of anyways would still work

nevermind

The only example where this would not work is if you had a function that insists it be called with nil and nil only. Then (keys {}) would be valid, but not if you spec it as seq. But that seems very unlikely in Clojure.

Ya, totally agree now. I really don't see why someone would ever use keys to a function that takes only nil.

I was thinking it would fail when passed to a fn on seqable input, that was my only concern

I think in general it works out if functions are typed with correct inputs (broad enough) but somewhat too narrow outputs.

In static linting

Thanks for the discussion

You probably have the most experience there, so I trust you in that observation

It does make sense, especially in linting, since you can just ignore a few false positive in the rare edge case

if you spec a function with a too narrow output (a instead of a or b) and you feed the output into a function which expected a or b, it still works fine.

right, makes sense

If I had say a function, and it could return nil or a seq based on the implementation, and I said it returns a seq, that would warn ?

Like say the last thing I return is the result of next

I am tossing in two cents based upon no real knowledge of clj-kondo internals, but I was under the impression that for certain core functions, borkdude simply tells it in some data structure "I claim that this returns type foo", and clj-kondo uses that, but does not check it.

"I claim that keys always returns a seq" that's how it works yes. And no code breaks on that assumption. If there would be code broken by this assumption, it's probably too specific

breaks as in false positive warnings

Okay, I see for core. What about for my code being linted? Do you just check inputs as well? So if I return the result of next and I claimed my fn returns seq only, it would be valid?

return type checking isn't implemented yet

Is clj-kondo's mechanism for declaring function return types open to user extension?

it is, via a configuration format

Just asking out of curiosity by the way, I don't have any grudge either way

ok cool

https://github.com/borkdude/clj-kondo/blob/master/doc/types.md

that's how it works. not a lot of people are using this format already and I want to give it some time before committing to it, but it is open to configuration

There is one schema library (malli) which is going to try to generate this format from information that users provide via their defn-like macro

Excited to see where this all goes, if more library authors start providing clj-kondo type configurations for their libs, linting would get really great

I have not read this book, but the author has worked on libraries for using Clojure to generate code for GPUs, and I believe reinforcement learning is one of the use cases he covers: https://aiprobook.com/deep-learning-for-programmers/

Thanks. Yep, I threw in to support the project, and I can now read his book. He's got general neural networks addressed, but upon first skim, I don't really see anything for reinforcement learning. Still looks promising for other areas I care about though...

I do not know how open the author is to suggestions for additional chapters, but you could try contacting him to see his plans for covering reinforcement learning, if any