Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-03-28

Channels

#clojure
<
2022-03-28
>
vlaaad09:03:35

(defmacro symap [& exprs]
  (zipmap (map keyword exprs) exprs))

(let [a 1 b 2]
  (symap a b))
=> {:a 1
    :b 2}
that sweet sweet syntax sugar…

borkdude09:03:12

I've used that exact same macro (but different name) in a work project once :)

potetm11:03:04

why keywordize the symbol?

vlaaad11:03:00

It's like a syntax sugar in js to build maps with keys from names of locals. Keywords are natural keys.

potetm12:03:04

so are symbols 😄

p-himik12:03:33

Not as much: 

=> (identical? 'a 'a)
false
=> (identical? :a :a)
true

🙌 1
potetm12:03:00

what difference does that make?

Ben Sless12:03:18

Map lookup is hash lookup + equality. If keywords are identical their equality check is very fast, almost free relative to the lookup

🙌 1
potetm13:03:29

I’ve not tested it, but I’m gonna guess that the longest part of this process isn’t the equality check.

potetm13:03:49

At any rate, I was making a suggestion to @U47G49KHQ — not looking for an empty debate with no constraints 😄

Carlo12:03:00

Interesting, in cljs: 

(identical? :a :a)
;; => false

☝️ 1
😨 1
potetm13:03:24

they’re exploiting an implementation detail

potetm13:03:30

it’s stable — not gonna change

ribelo21:03:02

cljs has keyword-identical? fn

🙌 1
genmeblog12:03:33

identical or not you can't make {'a 1 'a 2} or {:a 1 :a 2}

Carlo12:03:44

sorry, not sure I follow

genmeblog12:03:16

I refer to comment by @U2FRKM4TW which (I possibly misunderstood) wanted to show that not identical keys could be used as map keys.

🙌 1
genmeblog12:03:35

Ignore my twisted reasoning

Carlo12:03:51

Oh yes, they can, I assumed the original argument was that it makes equality more complicate (but I possibly misunderstood too 🙂)

Ben Sless12:03:18

Map lookup is hash lookup + equality. If keywords are identical their equality check is very fast, almost free relative to the lookup

🙌 1
borkdude14:03:02

A while ago I changed the organization name of SCI from borkdude/sci to org.babashka/sci . This caused quite a few problems, since some people included both as (transitive) dependencies and while they though they were using the newest, they were actually hitting the old library. I've been through quite a few repos making PRs to move to the new org. Now I'm trying to come up with one last thing: do one more update to borkdude/sci and print a warning on requiring sci.core that people should move to org.babashka/sci. Do you think that's a reasonable thing to do?

👍 1
didibus04:03:26

Seems like there'd need to be a redirect feature in the Maven protocol for that. I wonder if there is one such mechanism and we don't know?

didibus04:03:15

Now I'm not sure if Clojars and/or tools.deps or pomegranate support the relocation feature of Maven 2. It seems like a good feature to support.

borkdude10:03:40

@U0K064KQV very interesting!

Cora (she/her)14:03:11

longer answer: that sounds like a kind and thoughtful way of helping people. if you want to be extra nice you could make it so the library has a way of disabling that warning for those who can't or don't want to move

👍 2
Joshua Suskalo15:03:44

How much does printing a warning do? Are there people that are bumping dependencies on sci but aren't aware of the groupid change? If not, then the old version will be included without a warning. Maybe I'm seeing this wrong and enough people are using tools like neil that you'd see projects update sci to the latest, but I don't know.

borkdude15:03:44

At least I would reach the people who auto-upgrade their deps using a tool like antq, neil, lein ancient, etc. Can't reach everybody.

seancorfield17:03:13

@borkdude antq seems to have been pretty good about identifying group changes for me -- no idea how it does it.

👍 1