This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (12)
- # beginners (159)
- # boot (3)
- # calva (41)
- # cider (48)
- # clara (2)
- # clj-kondo (8)
- # cljdoc (8)
- # clojure (70)
- # clojure-dev (10)
- # clojure-europe (2)
- # clojure-losangeles (1)
- # clojure-nl (12)
- # clojure-spec (7)
- # clojure-uk (63)
- # clojurescript (24)
- # cursive (24)
- # datomic (22)
- # expound (17)
- # figwheel (1)
- # fulcro (176)
- # graphql (23)
- # jobs (9)
- # jobs-discuss (56)
- # kaocha (1)
- # mount (3)
- # nyc (1)
- # off-topic (91)
- # onyx (3)
- # overtone (4)
- # pathom (3)
- # pedestal (1)
- # re-frame (11)
- # reitit (19)
- # ring (8)
- # shadow-cljs (16)
- # test-check (5)
- # testing (2)
- # tools-deps (20)
- # vim (9)
all in all, this typehint does look very cryptic to me, but I guess the combination of arrays/types is almost too infinite for a special typehint symbol to be implemented for each and one of them?
well, I'll get used to it, I'd imagine all alternatives would conflict with the reader
every-pred's docstring doesn't guarantee the order of evaluation, just that it will stop on the "first" one that returns a logical false value. Is it improper to do
((every-pred integer? even?) nil)? Are we guarnteed that
integer? will check before
You can take a look at the source and see it is just using
@jimmy I see the source now allows for that. But I want to know if clojure will guarantee this going forward or if it just happens to be ordered now
I know you think the doc string is ambiguous, but arguments are vectors, not sets. It does say it takes the first argument and that it short circuits. Short circuiting is an ordered operation. But more than that Clojure takes backwards compatibility very seriously. Changing the order would be a huge breaking change. It will remain that way for as long as Clojure exists.
I don’t believe the arg is a vector. I understand the backward comparability but I’m not sure this is considered a contract of every pred or just an implementation detail
Maps are ordered up to 8 elements. But it’s not in a docstring so relying on it is crazy and it’s best ignored
The docstring is trying to say that. But it is just not explicit. "Note that f is short-circuiting in that it will stop execution on the first argument". I know you think this is ambiguous, but arguments to a function are ordered and that is what first is referring to here. The docstring definitely isn't going to change to remove the ambiguity. But this code hasn't changed in 8 years and won't change in the future.
Also test cases imply this.
;; 2 preds, short-circuiting false ((every-pred number? odd?) 1 :a) false ((every-pred number? odd?) 1 3 :a) false ((every-pred number? odd?) 1 3 5 :a) false ((every-pred number? odd?) 1 3 5 7 :a) false ((every-pred number? odd?) 1 :a 3 5 7)
Hello every one. Are there any reporting tools available in Clojure. Any body tried integrating BIRT into your clojure app ?
@jimmy The docstring is clear that the returned function
f will short-circuit on the "first argument" but says nothing about the order of the predicates. Just the order of arguments to
So I'm with @dpsutton that the docstring gives no explicit guarantees about the order that
f will apply the predicates (to each argument).
It just says it will stop at the first argument for which not all the predicates return false. It could apply the predicates in any order.
It would still be a very large breaking change. And the tests seem to expect that the preds are applied in order.
Aye, I agree it would be unlikely -- but it is still an implementation detail -- and the core team has changed implementations occasionally in the past that break behavior that was not guaranteed by the docstring.
I sometimes wish there was a bit more chaos in programming. Things that werent guaranteed randomly changing behaviour
Years ago, I worked on a C compiler system that deliberately had variable behavior for undefined and unspecified situations 🙂
It was a code checking system, so it detected these situations explicitly in the runtime and handled them -- rather than just letting things blow up or always behaving in a predictable manner 🙂
The confusion stems from both
every-pred and the function it returns both being variadic.
i think i remember him envisioning conds all working like that. thought it was right around the corner
https://dev.clojure.org/jira/browse/CLJ-1872 - empty? is broken for transient collections I spent a little time staring at what it would take to submit a patch for this. Do I understand correctly that RT seqFrom and RT canSeq would need to include logic for TransientVector and company?
I feel like I've seen this pattern over and over - transient collections working for a specific use case (blindly accumulate items in one big reduce then persist), and all kinds of ops we expect for collections not working or working weirdly on transient collections
the bugs get fixed eventually (I don't know if any of the collection features have been called wontfix yet), but they keep coming up
also iirc at best that transient coll will give you ~15% perf boost, and that's if it's in your main bottleneck