Fork me on GitHub

Good Morning!


well that was a fun macro...

Ben Hammond09:09:16

what is mlet?

Ben Hammond09:09:44

not that I'm condoning this sort of disgraceful behaviour...

Ben Hammond09:09:08

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

Ben Hammond11:09:18

this is bonkers I can't get it though my > I believe that filter

Ben Hammond11:09:08

but what a great way to cheat at your munro bagging

Ben Hammond11:09:44

doesn't say how long the fuel lasts for of course

Ben Hammond11:09:09

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


I mean maybe I have live objects in my repl I do not want to discard and recreate


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


Sounds like the lib and the application agree here though?


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


I found this a bit funny


there are apparently 63 ways of writing a multi-line string in yaml


Yaml is a bit excessive 😀