This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-29
Channels
- # announcements (1)
- # babashka (120)
- # beginners (184)
- # cider (14)
- # clara (2)
- # clj-kondo (25)
- # cljfx (9)
- # cljsrn (43)
- # clojure (46)
- # clojure-australia (2)
- # clojure-berlin (5)
- # clojure-dev (2)
- # clojure-europe (10)
- # clojure-france (3)
- # clojure-nl (1)
- # clojure-spec (14)
- # clojure-uk (30)
- # clojurescript (50)
- # code-reviews (19)
- # conjure (11)
- # core-logic (2)
- # cursive (20)
- # datascript (1)
- # datomic (74)
- # figwheel-main (1)
- # fulcro (10)
- # funcool (2)
- # graphql (1)
- # lambdaisland (1)
- # malli (2)
- # meander (22)
- # nrepl (13)
- # off-topic (28)
- # overtone (3)
- # pathom (7)
- # pedestal (4)
- # re-frame (4)
- # reagent (16)
- # reitit (4)
- # releases (1)
- # ring (8)
- # shadow-cljs (93)
- # specter (6)
- # sql (13)
- # test-check (1)
- # tools-deps (1)
- # tree-sitter (2)
- # vim (8)
- # xtdb (25)
månmån
well that was a fun macro...
what is mlet
?
not that I'm condoning this sort of disgraceful behaviour...
I do enjoy the way the Clojure makes macros visually look like you are swearing
mlet
is monadic-let... like the do
syntax in haskell, a nice way of composing bind
operations
i would have been lost without the internet ( https://turbofuture.com/computers/Clojure-macro-writing-macros )
morning
this is bonkers https://www.bbc.co.uk/news/uk-england-54331994 I can't get it though my > I believe that filter
but what a great way to cheat at your munro bagging
doesn't say how long the fuel lasts for of course
presumably they have to hike back down the hill lugging the rocket engines
opinion solicited: put protocols in a separate namespace to avoid recompilation dependency issues during dev, or leave them in their "natural" namespace and use c.t.n.r/refresh
when things get screwy ?
protocols on their own are never dependent on anything so can be require'd from anywhere, so in an application I always put them in their own file to avoid headaches.
but are there any headaches other than the protocol getting recompiled mandating the recompilation of everything that uses it ?
i've always done the same, put them in a separate file, but i'm wondering if there's any need now that c.t.n.r/refresh
exists
ah, ok, interesting. i don't really do that
but still, that concern affects the code you are working on, but not libs you consume... so you wouldn't really care if some lib didn't separate out its protocols ?
Clojure uses separate file, with function elsewhere. That allows you to do useful things like swapping arguments or adding specific overrides.
ah, yeah, in the style of reduce-kv
if you are working on a lib there are good reasons to keep the protocols exactly where you want them (say if they form part of the api, expectation user will extend them). and absolutely repl convenience has to take a back seat during lib dev. I was talking from an application development standpoint, where repl convenience I think has to win out a bit more
as it turned out, most of the protocol fn invocations were already hidden behind macros (which fill in a context param), so moving the protocols to another ns was straightforward