What's people takes on shadowing global vars with local ones? Like say calling a local binding str ?

don’t do it

been bitten more times than i can count by naming things type and then messing up a reference somewhere in the file

I only shadow when I intentionally want to make a var unavailable

Perfectly fine, I do it all the time

(e.g (fn [a] (let [a (normalize a)] …)) )

Haha, so I guess its a controversial issue 😛 I'm in the camp of it being totally fine as well. I've never really gotten confused by it, though I guess it would be confusing if it binds to a function. Like a function that took an arg called str which also happened to be a function, that be confusing. But I've never done that.

It's bitten me once or twice but I still do it. There are just too many nice, short, useful names in clojure.core to avoid them all for local bindings.

type and name are probably the two most common global names that I shadow @didibus -- I have str as an alias for clojure.string but I've never found a need for it as a local symbol. A generic string might just as well be s 🙂

(it would be interesting to scan the codebase to see what else we shadow... is that something clj-kondo can detect @borkdude? I suspect it is... but off by default?)

I remember him asking about this recently. It might be recently added or abandoned based on feedback

I’ve been bitten by name a few times. I get nervous each time I use it as a var

:shadowed-var -- off by default. Just looked it up.

Maybe I'll turn it on at work and see what we get 🙂

at some point, the number of experts who have been bitten by it says all you need to say

probably 🙂

t and n are fine for type and name, imo

I realized you can freely mix vars and namespace, so even when I alias clojure.string as str its still fine to do: (fn [str] (str/upper-case str))

Even clojure code uses s for strings

extremely common abbreviation

*clojure core

But I alias clojure.spec.alpha to s 😛

alias/var names don’t overlap

never had a single issue with that 🙂

(because it’s impossible)

Anyway, I was just using it as an example. The example that prompted me to ask was we have a thing called Agent in our app, and so the bindings are often (defn [agent ...] ...) and our team were discussing not shadowing the core agent function. So maybe that's a better example?

Heh. I never use agents so shadow away. There’s basically no ambiguity for me :)

Yes, clj-kondo has a linter for that. I fixed an issue with it on master last weekend

Humdum, trying to remember the name of a tracing debug library for Clojure that came about recently (not sayid), but my memory fails me

hi, I have a quick question: I have this list of strings that are all numeric. Before I process it, I map over the list to get numeric values: (map (Integer/parseInt %) my-list) I compile it with no complaint. However, when I run the code, the first time I run it I get a number format exception for the value of "2622048027". When I run it the second time without changing code or recompiling or anything, the code works fine. I understand that Integer/parseInt is supposed to give number format exception. What I do not understand though is why it works the second time I run the code. Anyone has any idea what is happening here?

map is lazy so if you're not using all of the result, you won't actually do the parsing

@alexmiller I get that, but what is getting "2622048027" to be a number the second time I run the code?

the first time I need that value, map is evaluated, and that is when (Integer/parseInt "2622048027") is called, and it gives the exception. The second time I run the code, Integer/parseInt has already been called, so it is not called... buut what got "2622048027" into 2622048027?

I think that number is too big to be an Integer

Integer/MAX_VALUE is 2147483647

in general, I almost always use Long/parseLong (because that's the default integer size in Clojure)

it is, and I understand why Integer/parseInt must throw an exception. But I do not understand how it is turning into a number in spite of the eception being thrown

can you share the actual code?

from your description, doesn't make sense so must be missing something

yes sure. the code is my solutions to advent of code. I am giving url directly to day 9 solution https://github.com/bibiki/aoc-2020/blob/main/src/aoc_2020/day_9/solution.clj

if you fetch the code and want to reproduce the bug, just run (solution-second-part) twice after compiling the code

This is surprising:

(case (int -1)
  -1 true
  nil false)
Execution error (IllegalArgumentException) at .../eval21818 (form-init2370325502731369149.clj:398).
No matching clause: -1

(case (int -1)
  -1 true
  -2 false)
true

that is a bug and we have a ticket for it

https://clojure.atlassian.net/browse/CLJ-2275

well, maybe it's not the same thing - you might be seeing mismatch between int and long too?

nah, it's probably the same thing as that bug

Yeah, this works:

(case (int 1)
  1 true
  nil false)
true

What's the best way to synchronize a function in Clojure? For all its callers?

locking is the canonical answer

functions are not synchronized in Clojure, but you can add that semantic inside the function if you really need to

(but I'd try hard to not need to :)

locking lets you use the low level object monitors that synchronized blocks and methods in java use, but you also have access to https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/package-summary.html

What's the best thing to lock on if using Locking?

Can I lock on the function itself?

I wouldn't

common case is to def/let an (Object.) to act as the lock

Would this be considered weird:

(let [o (Object.)]
  (defn ...
    (locking o ...)))

no, but I'd put that around the defn

not in the defn

yeah, have done

Sorry, updated it, pressed enter instead of shift+enter first time around

np, that is a pattern for sure