Thank you, I see it now. Based on your comment I actually took at look at
the source code for "every?" (haven't checked it before, oddly enough)
=> (source every?)
(defn every?
"Returns true if (pred x) is logical true for every x in coll, else
false."
{:tag Boolean
:added "1.0"
:static true}
[pred coll]
(cond
(nil? (seq coll)) true
(pred (first coll)) (recur pred (next coll))
:else false))
nil
I thought that by "coll" in the doc they meant "coll?" returns true on the
input...
But now I see that first does a seq on that coll which does what you said
and thus returning a vector
So these mean nothing:
=> (seq? {:a :b :c :d})
false
=> (coll? {:a :b :c :d})
true
=> (seq? [:a :b :c :d])
false
=> (coll? [:a :b :c :d])
true
=> (first [:a :b :c :d])
:a
=> (first {:a :b :c :d})
[:a :b]
=> (first {})
nil
=> (first [])
nil ;if this were me I'd probably choose to throw here
;or return all values in a vector to differentiate from the following:
=> (first [nil])
nil
It kinda makes sense except I wouldn't have expected that on the map it
would return a vector (but then how else could it return both key and value
right? ) so everyone expects the "input" to the pred would be a vector
when passed in a map.
oops stumbled upon another one:
=> (get [1 2 3] 0)
1
=> (get [1 2 3] -)
nil
=> -
#<core$_ clojure.core$_@2b0dfb46>
Yep definitely better than throwing *sarcasm*
ok check this:
=> (every? nil? nil)
true
=> (every? nil? [nil])
true
=> (every? nil? [])
true
=> (every? true? [])
true
=> (every? true? nil)
true
=> (every? true? [nil])
false
=> (first nil)
nil
=> (first [nil])
nil
=> (first [])
nil
makes me think of C or something
(ok i'll stop if nobody brings it up, but really thanks to everyone that
replies - and sorry for hijacking the thread)
On Fri, May 24, 2013 at 8:21 PM, Alan Thompson <thompson2...@gmail.com>wrote:
> 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.
>
>
>
--
--
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.
