Questions about some-fn and every-pred (possible bug, and improvements)

53 views
Skip to first unread message

Max Penet

unread,
Oct 25, 2012, 6:31:57 AM10/25/12
to clo...@googlegroups.com
Hello, 

I am trying to understand the rationale behind the current implementation of some-fn and every-pred, there seems to be a couple of odd things, or maybe that is just me misunderstanding their doc.

user> ((every-pred (fn [_])))
true
user> ((some-fn (fn [_])))
nil

Shouldn't the first example return false? since the first function always returns nil? 

I was also wondering if it would make sense to add a 0 argument version of these, it would make their usage with apply more convenient, and comp which has a smiliar signature behaves like that: 

user> ((comp) true)
true

user> ((some-fn) true)
; Evaluation aborted.

user> ((every-pred) true)
; Evaluation aborted.

Max

Max Penet

unread,
Oct 25, 2012, 6:49:08 AM10/25/12
to clo...@googlegroups.com
user> (every? identity [])
true

I think I understand now, this might be to match the behavior of "every?".

Max

Tassilo Horn

unread,
Oct 25, 2012, 6:48:25 AM10/25/12
to clo...@googlegroups.com
Max Penet <m...@qbits.cc> writes:

> user> ((every-pred (fn [_])))
> true
> user> ((some-fn (fn [_])))
> nil
>
> Shouldn't the first example return false? since the first function
> always returns nil?

No. ((every-pred a b c) o1 o2 ...) returns true if all predicates a, b,
and c return true for all given args o1, o2, and so one. You don't pass
any args, so this is basically (and), which also returns true. `and` is
true if all arguments are logically true, which is trivially given when
none are provided.

> I was also wondering if it would make sense to add a 0 argument
> version of these, it would make their usage with apply more
> convenient, and comp which has a smiliar signature behaves like that:
>
> user> ((comp) true)
> true
>
> user> ((some-fn) true)
> ; Evaluation aborted.
>
> user> ((every-pred) true)
> ; Evaluation aborted.

(comp) is `identity` which makes sense. What would the semantics be for
every-pred and some-fn? IMO, it should be

user> ((some-fn) <no-matter-what>)
false
user> ((every-pred) <no-matter-what>)
true

e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was
equivalent to (constantly true).

Bye,
Tassilo

Max Penet

unread,
Oct 25, 2012, 7:05:52 AM10/25/12
to clo...@googlegroups.com


On Thursday, October 25, 2012 12:49:32 PM UTC+2, Tassilo Horn wrote:
Max Penet <m...@qbits.cc> writes:

> user> ((every-pred (fn [_])))
> true
> user> ((some-fn (fn [_])))
> nil
>
> Shouldn't the first example return false? since the first function
> always returns nil?

No.  ((every-pred a b c) o1 o2 ...) returns true if all predicates a, b,
and c return true for all given args o1, o2, and so one.  You don't pass
any args, so this is basically (and), which also returns true.  `and` is
true if all arguments are logically true, which is trivially given when
none are provided.

Ok that makes sense. 
 

> I was also wondering if it would make sense to add a 0 argument
> version of these, it would make their usage with apply more
> convenient, and comp which has a smiliar signature behaves like that:
>
> user> ((comp) true)
> true
>
> user> ((some-fn) true)
> ; Evaluation aborted.
>
> user> ((every-pred) true)
> ; Evaluation aborted.

(comp) is `identity` which makes sense.  What would the semantics be for
every-pred and some-fn?  IMO, it should be

user> ((some-fn) <no-matter-what>)
false
user> ((every-pred) <no-matter-what>)
true

e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was
equivalent to (constantly true).

Yes I understand that, the proposal was just to avoid exceptions when used with apply, but this could end up be bit confusing maybe, and it can be tested beforehand anyway. 

Max

Tassilo Horn

unread,
Oct 25, 2012, 7:41:12 AM10/25/12
to clo...@googlegroups.com
Max Penet <m...@qbits.cc> writes:

Hi Max,

>> user> ((some-fn) <no-matter-what>)
>> false
>> user> ((every-pred) <no-matter-what>)
>> true
>>
>> e.g. (some-cn) was equivalent to (constantly false) and (every-pred) was
>> equivalent to (constantly true).
>
> Yes I understand that, the proposal was just to avoid exceptions when
> used with apply, but this could end up be bit confusing maybe, and it
> can be tested beforehand anyway.

No, I think it's a valid request and it wouldn't be more confusing than
(and) => true (or) => false. I'll create a ticket and patch for it.

Bye,
Tassilo

Tassilo Horn

unread,
Oct 25, 2012, 8:11:10 AM10/25/12
to clo...@googlegroups.com
Done, see http://dev.clojure.org/jira/browse/CLJ-1094

In contrast to what's written above, I decided to make (some-fn) to be
(constantly nil), which matches the behavior of `some` better than
(constantly false).

Bye,
Tassilo

Max Penet

unread,
Oct 25, 2012, 8:20:17 AM10/25/12
to clo...@googlegroups.com
Thanks, perfect, I had prepared a patch that was identical.
Reply all
Reply to author
Forward
0 new messages