Usage: (every? pred coll)
(see http://clojuredocs.org/clojure_core/clojure.core/every_q )
Function *every?* expects a predicate and a collection. Converting the map
{:a 1} into a collection returns a sequence of 2-element vectors:
user=> (seq {:a 1})
([:a 1])
Calling the function :a on a vector returns nil, since keyword lookup only
works for maps. every? then converts the nil into fase:
user=> (every? :a [ nil ] )
false
Alan
On Thu, May 23, 2013 at 7:22 PM, atkaaz <atk...@gmail.com> wrote:
> Firstly let me just say that I really enjoy this conversation, ergo I
> thank you!
>
>
> On Thu, May 23, 2013 at 9:00 PM, Michał Marczyk
> <michal.marc...@gmail.com>wrote:
>
>> On 23 May 2013 18:30, atkaaz <atk...@gmail.com> wrote:
>> > when you say the word "false" I'm assuming you're referring to "false?"
>> the
>> > function (not "false" the boolean value), otherwise I don't understand
>>
>> I mean false-the-Boolean-value.
>>
>> To rephrase the point I was making previously, "(false x) is a truthy
>> value for any x in []" is a true sentence, indeed trivially so because
>> [] is empty. Thus (every? false []) returning true totally makes
>> sense.
>>
>> Alright, I see what you mean and you are right. But let's just state some
> assumptions(which I see as conventions):
> - the system that you're using (be it logic or mathematics or whatever it
> is) to evaluate that that proposition is truthy is assuming(without
> checking) that the components are correct (such as "false" being a pred)
> - when the collection is empty -> returns true (this is a convention
> imho)
> I see this system as being incomplete/incoherent/inconsistent(or insert
> the right word here) because of those.
> "(false x) is a truthy value for any x in []"
> so that is a true sentence as you say, in this system(can I call it logic?
> or whatever you call it really) of evaluation which you can collapse to the
> implementation of "every?" as it is now in clojure. You may even say that
> the implementation of "every?" was based on that(doesn't matter). But I say
> that system is "wrong" xD so to speak, "wrong" as in
> incomplete/inconsistent and may work somewhere else (in non-programming
> environments ie. on paper) where assuming that the input is valid is the
> norm /the only thing happening.
> In a programming environment, for me it doesn't make sense to can call or
> evaluate something that has (at least one) inconsistent components
> (inconsistent based on its own definition).
> => (every? 1 [])
> true
>
> So it is truthy as you say, but that doesn't mean anything other than it
> is so(by convention/definion of) in this or that specific system(logic? or
> the impl. of "every?" in clojure)
> That may be acceptable to clojure community or to ppl who want to get
> work done, but not to (some) people who want/care for a consistent(ly
> defined) system. Ok, sure, I'm free to implement any constrains on top of
> that but if they were already implemented I couldn't get rid of them: I'll
> grant you that reasoning for keeping it the way it is now. But it's little
> things(inconsistencies I'll call them) like this which will make way for
> bugs which can be hard to track down. There's no guarantee that someone
> sometime will pass the wrong param either being aware of it or not and
> depending on the case it may go unnoticed and/or throw in a different place
> which seems quite unrelated to where the bug actually is.
> Anyway, I'm lingering, simply put: you're right using your system of
> evaluation, but not when using mine; mine says: make sure everything is
> consistent within its own definition (so "1" above must be checked if it
> really fits the "pred" pattern (ie. is that a pred; is the entire
> proposition(or call) syntactically&semantically valid), if it doesn't the
> the entire call is invalid and should/will throw) and I will add to that:
> that if the collection is empty then also throw, for it doesn't make
> sense(to me) to check an empty collection (which you sort of assume is non
> empty by the name "every?") for a predicate, and therefore you are kind of
> forced to use a convention(aka "if empty return true") if you want to not
> throw in this case. (yep I would really throw on empty collection, for if
> you got to where you accidentally called every? on an empty collection
> you're way past the point in the caller where you should've checked for an
> empty collection anyway - that is, if you care about handling all(or most?)
> cases for the purpose of your program being consistent)
>
>
> So, assuming non-empty collections are the norm, we get an exception
>> either way -- would having the exception come from every? rather than
>> the attempt to call the not-really-a-predicate object be of much help
>> in debugging?
>>
> I find it would be more consistent to throw from every? as if it makes the
> check that all its inputs are correct (so making sure pred is a pred ie. a
> fn and not a value - that can't be used as a pred at least like a :keyword
> could)
> And also, as I said above, I'd throw when empty collection too (but that's
> never gonna happen in clojure, I understand that especially because of what
> John D. Hume said in an above post - makes sense(if you want to get things
> done especially), but that is not my way(hence why I got nothing done so
> far - so the joke's on me :) ))
>
> wait, shouldn't this work?
> => (:a {:a 1})
> 1
> => *(every? :a {:a 1})*
> false
> => (coll? {:a 1})
> true
>
>
> ;well at least this one works:
> => (every? {:a 1} [:a])
> true
> => ({:a 1} :a)
> 1
> ;so I'm probably missing something
>
>
>> Cheers,
>> M.
>>
>> Cheers & thank you for this great interaction!
>
>>
>> >
>> > so like: "What matters is that false? returns truthy values when called
>> with
>> > any members of []"
>> > makes sense to me.
>> >
>> > So all I was saying above is that it should throw when [] is empty just
>> as
>> > it does when [] is not empty, but it doesn't throw when empty because
>> it's
>> > never called (by "it" i mean "false" not "false?")
>> >
>> > => (type false)
>> > java.lang.Boolean
>> > => (type false?)
>> > clojure.core$false_QMARK_
>> > => (fn? false)
>> > false
>> > => (fn? false?)
>> > true
>> >
>> > But really, if you were not talking about "false?" then I don't get it
>> (??)
>> >
>> >
>> > On Thu, May 23, 2013 at 4:48 PM, Michał Marczyk <
>> michal.marc...@gmail.com>
>> > wrote:
>> >>
>> >> Whether (false 1) or (false true) is truthy is irrelevant. What
>> >> matters is that false returns truthy values when called with any
>> >> members of [], which is of course the case, as [] has no members. (For
>> >> it not to be the case, there would have to exist an x in [] for which
>> >> (false x) were not truthy -- clearly there is no such x.)
>> >>
>> >> This is the same story as with quantification restricted to the empty
>> set:
>> >>
>> >> \forall x \in \emptyset . \phi(x)
>> >>
>> >> is true regardless of what \phi is, and intimately related to how
>> >> implication works in classical logic (since the above is shorthand for
>> >> a formula involving implication):
>> >>
>> >> x -> y
>> >>
>> >> is true when x is false, regardless of what value y takes. (It's also
>> >> true when y is true, regardless of what value x takes; this, however,
>> >> is not relevant here.)
>> >>
>> >> Cheers,
>> >> M.
>> >>
>> >>
>> >> On 23 May 2013 06:31, atkaaz <atk...@gmail.com> wrote:
>> >> > Well, seems to me more like this:
>> >> > if [] is empty then return true
>> >> > otherwise check (pred everyx in coll)
>> >> > however this allows for any pred especially(in this case) invalid
>> preds:
>> >> > `false` is not a function/pred
>> >> > => (false 1)
>> >> > ClassCastException java.lang.Boolean cannot be cast to
>> clojure.lang.IFn
>> >> > cgws.notcore/eval2542 (NO_SOURCE_FILE:1)
>> >> > => (false true)
>> >> > ClassCastException java.lang.Boolean cannot be cast to
>> clojure.lang.IFn
>> >> > cgws.notcore/eval2564 (NO_SOURCE_FILE:1)
>> >> >
>> >> > doesn't seem truthy to me
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> > On Thu, May 23, 2013 at 3:08 AM, Michał Marczyk
>> >> > <michal.marc...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On 22 May 2013 18:34, atkaaz <atk...@gmail.com> wrote:
>> >> >> > I think the exception is thrown because you basically called
>> (every?
>> >> >> > false
>> >> >> > coll) however on my clojure version I cannot reproduce it oh wait
>> >> >> > there
>> >> >> > we
>> >> >> > go, some bug here with empty collection (maybe someone can pick it
>> >> >> > up):
>> >> >> > => (every? false [1 2 3])
>> >> >> > ClassCastException java.lang.Boolean cannot be cast to
>> >> >> > clojure.lang.IFn
>> >> >> > clojure.core/every? (core.clj:2423)
>> >> >> > => (every? false [])
>> >> >> > true
>> >> >> >
>> >> >> > => *clojure-version*
>> >> >> > {:interim true, :major 1, :minor 6, :incremental 0, :qualifier
>> >> >> > "master"}
>> >> >>
>> >> >> (every? false []) should return true if and only if (false x) is
>> >> >> truthy for every x in [], which is certainly the case.
>> >> >>
>> >> >> Cheers,
>> >> >> Michał
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Wed, May 22, 2013 at 7:17 PM, Peter Mancini
>> >> >> > <peter.manc...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> So I did some coding and came up with this but it is broken;
>> >> >> >>
>> >> >> >> (= java.lang.Boolean (type false)) ;;evaluates to true
>> >> >> >>
>> >> >> >> (defn all-true?
>> >> >> >> [coll]
>> >> >> >> (every? (cond (= java.lang.Boolean (type identity)) identity
>> :else
>> >> >> >> false) coll)) ;;compiles
>> >> >> >>
>> >> >> >> (all-true? '(true true true)) ;; throws
>> >> >> >> java.lang.ClassCastException:
>> >> >> >> java.lang.Boolean cannot be cast to clojure.lang.IFn
>> >> >> >> (all-true? '(true true false))
>> >> >> >> (all-true? '(true true 3))
>> >> >> >>
>> >> >> >> --
>> >> >> >> --
>> >> >> >> 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/groups/opt_out
>> .
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > --
>> >> >> > 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/groups/opt_out.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> --
>> >> >> 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/groups/opt_out.
>> >> >>
>> >> >>
>> >> >
>> >> > --
>> >> > --
>> >> > 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/groups/opt_out.
>> >> >
>> >> >
>> >>
>> >> --
>> >> --
>> >> 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/groups/opt_out.
>> >>
>> >>
>> >
>> > --
>> > --
>> > 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/groups/opt_out.
>> >
>> >
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
> --
> --
> 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/groups/opt_out.
>
>
>
--
--
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/groups/opt_out.
