ClojureScript portability is probably the best reason. The other one is usage in spec. They don't all need to go in core, but going in the standard lib would be nice, like clojure.type-predicates.
Even better if we had clojure.types. And it could have both predicates and types defined in it. So you'd find atom? and all others in it, but you'd also have atom-type. So when you implement a protocol for both clojure and clojurescript, you could use types from clojure.types as a way to make it work for both. (extend-protocol wtv atom-type ...) While this could be made a lib, since its primary usefulness is portability with other Clojure dialects, I think it makes more sense to have it bundled with Clojure. On Saturday, 5 August 2017 04:04:01 UTC-7, Alex Baranosky wrote: > > Do we want a predicate for every interface? I, for one, DEFINITELY do not. > Just make some utils if you need to check for (instance? IAtom x) a lot in > your application. All such fns do is bloat clojure.core. > > On Sun, Jul 16, 2017 at 5:24 PM, Alex Miller <al...@puredanger.com > <javascript:>> wrote: > >> The decisions for volatile? vs other predicates were made at different >> times so I don't think there is necessarily any guiding design principle >> behind having one vs not having the other. I wrote the volatile addition, >> but I don't remember any of the details around why we included volatile? at >> that time. >> >> The broader question is, do we need a predicate for every interface? Is >> this worth having vs just #(instance? clojure.lang.IAtom %). One reason a >> predicate can be useful is for portability with ClojureScript, so I think >> that adds a little more weight to atom? (and none for ref? or agent?). >> >> Another question is where this would be useful - what could do you >> envision where it's helpful to have it. If it's not common, then it's not >> worth having yet another function in core that needs to be loaded. >> >> And another question is how prevalent this function is "in the wild" >> either as a predicate or even more interestingly as something else. >> clojure.inspector and cider.nrepl actually have an atom? that is more of >> the traditional lisp/scheme sense of a non-collection. I see other impls of >> atom? in places like plumatic schema, taoensso encore, hara.common.checks, >> seesaw, and many others. (All of those impls are actually dated in that >> they check for the concrete class Atom rather than the interface IAtom that >> was introduced in 1.7.). See https://crossclj.info/clojure/atom%3F.html >> for more definitions. >> >> Having many existing impls of this function out there means that we >> either introduce warnings, or worse we actually introduce a core function >> that has different semantics - there are many similar functions that >> instead check for Atom, and some that do something entirely different. >> >> Weighing all this, I can't say that adding atom?, ref? (likely to have >> way more conflicts with different semantics), or agent? seems like a big >> win to me and is certainly not problem-free. When we added volatile?, that >> was not an existing overlap with many (or maybe any) existing functions out >> in the wild so was a little easier from that perspective. >> >> On Sunday, July 16, 2017 at 3:38:47 PM UTC-5, Shantanu Kumar wrote: >>> >>> Hi, >>> >>> Since Clojure 1.7 there's a `volatile?` predicate function, but no such >>> equivalent for atom/ref/agent. Can anybody explain the rationale behind the >>> difference? I found an old thread on a related topic (URL below) but would >>> like to know if there's an updated explanation. >>> https://groups.google.com/forum/#!topic/clojure/mIJK3x_SUyM >>> >>> >>> Shantanu >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
