typo, I meant: "thanks to everyone that replieD"
On Fri, May 24, 2013 at 9:25 PM, atkaaz <atk...@gmail.com> wrote:
> 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.
