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.
