Fork me on GitHub

Is there any Jira about having conditional requires as a feature? Like configurable conditional reader features. I have some place where it could be really handy and cleaner so that I do not pollute the code with namespaces I do not want at compile time


I did this with reader tagged literals #my/require-if (pred (:req... foo) (:req... bar))


Then used closure-defines to signal whether I'm pulling deps from a module based dep graph or a monolithically compiled project.


if closure-defines contains :modular true then instead require the namespaces that lazily load modules as necessary.


I think using a macro directly would mess with the ns declaration validation


But maybe not... I didn't test that method


Oh, and sorry all that module talk was about the CLJS side 😆


Soooo wirst of all great thank you! Is this working only with modules? Finally I am using shadow, are you using the vanilla compiler?


Vanilla CLJS


I wonder if @U05224H0W can confirm or deny this approach is working in shadow-cljs as well


Doesn't matter whether your using modules or not, but modules are what made this compile-time thing necessary for me.


in co.edn I've got a :closure-defines {my.conf/modular true}. In data_readers.cljc I've got {if/mod mod-base.macros/if-mod} and in mod-base.macros I've got:

(defn if-env [[if-str? then? else?]]
  (if (-> env/*compiler* deref :options :closure-defines (get if-str?))

(defn if-mod [[then? else?]]


and no there is no JIRA ticket about this. there was a "discussion" a while ago but that never went anywhere either.


Then the namespace declaration goes:

[(ns mod-one.lazy
   (:require-macros [mod-base.macros :refer [defxmod]]))
 (ns mod-one.lazy
   (:require-macros [mod-base.macros :refer [defxmod]])
   (:require [mod-one.main :as main]))]


probably not the cleanest way to structure it


But it works


that feature is awesome @U05224H0W that's exactly what I need


but props to @U050PJ2EU and thanks for coming up with this very creating way of doing it!


I think you should write a blog post (or delegate to someone who is willing to write me :D) that compares the two solutions


By all means! I think it's moreorless an accident that it works. There's probably a lot of other tricks waiting to be found down that road. But in cases where a macro could instead be used, that probably makes more sense.


That'd be awesome if you wrote up a blog post about it. I'm slacking on my blogging. Gotta get another static site up on a gh-pages.


I was using medium but their policies seem egregious now days.


if you let me, I think I have some time this weekend to put it up


and it is a controversial one so probably worth writing 😄


Should be fun! 🙂 lemme know if you want help reviewing it. Making an if-node version should be pretty easy if it can be pulled out of the compiler env


I'm looking through some Clojure code that has been decompiled to Java, looking for places to make performance improvements. I can't figure out how Clojure decides whether to call a function by its invoke or invokeStatic method. Can someone point me to an explanation of how this works? Thanks.


invokeStatic is used when aot compiling with direct linking. invoke is used otherwise (more common)

alexmiller12:08:36 is probably the only place I can think of with docs about direct linking


G'day I have a doubt about transducers style. Let me start with a silly example:


So silly-transducer1 needs to be a function that returns a transducer, to capture the extra parameter n. What about silly-transducer2? I could save 1 level of nesting, having directly (silly-transducer2 [rf] ... but then users would have to pay attention to the different way of using them. Is there a style rule about this?


@ammazza I haven't heard anybody give rules about this, but I'd make silly-transducer2 a function for consistency.

👍 1

Thanks @miikka. In the meantime I also found another reason for being consistent. The outermost wrapper can be used as in clojure/core to provide a Version that, if given a collection, applies the transducer to build a lazy seq. An example is dedupe


there has an bug on core.async --- writing still blocked even if chan closed!


I need to inject a var from project.clj to be available during compile-time. Any ideas?


Is there a way at run-time to discover the return type tag, if any, on a function?


what problem are you actually trying to solve?


I'm trying to write a library where the user supplies a function that can either return a double or an implementation of a protocol. It's very performance-sensitive, so some of the more dynamic ways I've tried to address this were too slow, so I was hoping to do some analysis of the function they supply ahead of time, and wrap it in the appropriate wrapper. Possibly I can see if it implements OODOD or vs OODOO or whatever the distinction is. That's the kind of thing I was thinking of. I'll continue to benchmark some other options too.


Speaking of which, is there any way in Clojure to make calling an interface method defined via definterface similar to the way you call protocol functions defined via defprotocol? I really need primitive return types on some of the functions so can't use protocols for those (at least, that's my understanding that there's no way to provide primitive type hints on a protocol), but I fear that if my library requires a mixture of implementing and calling interfaces and protocols, some with imports at the top, and some with namespaces, some looking like functions and some looking like .method, that would be thoroughly confusing.


for the sequence returning operations, like map, are there performance guarantees for resulting sequences? for ex. does (map inc [1 2 3]) return a sequence which has fast index lookup, like vectors?


No, map returns a seq, which is lazy.


You might be interested in mapv though, which returns a vector.


you can use mapv to get a vector have the fast lookup


Yes, be aware though, that mapv is not lazy.


yes, but I don't have a similar thing for hashmaps 🙂


@henrik thanks, so it's what I suspected. so with a sequence you are basically like with a list


@roti Yes, but lazy sequences can be very performant given certain circumstances, since they’re only realized when absolutely needed.


@roti have you looked at transducers? It provides the ability to use these transformation functions, like map, in a collection independent way


Eg (into {} (map f) m)