>..., do you think it's better to code
> it so that it always returns "t" for the true case?
my current practice is to use other-than-nil as truth value in
predicates. Even if current application needs t or nil only. this will
help avoid breaking older code (which did not assum
In article <4d307ce8.1000...@itasoftware.com>,
Daniel Weinreb wrote:
> If you have a function that is a predicate, in the sense that
> the function's contract says that its value should be interpreted
> as being either false or true, do you think it's better to code
> it so that it always return
--
Date: Sat, 15 Jan 2011 15:23:48 +0100
From: "Svante Carl v. Erichsen"
Subject: Re: [pro] Style issue about predicates
Hi!
I would not like such a rule in a style guide, for fear of religious
followers. My view is: yes, tighten the contract, but no, it needs
not (but may) specify ex
14 Jan 2011 17:59:52 +0100
From: Edi Weitz
Subject: Re: [pro] Style issue about predicates
There are lots of functions in the standard which are predicates in
that they return generalized booleans but on the other hand return
something "useful" if the result is not NIL, e.g. MEMBER or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I would not like such a rule in a style guide, for fear of religious
followers. My view is: yes, tighten the contract, but no, it needs
not (but may) specify exactly t. If something useful can be returned,
why throw it away?
Best wishes
Svante
ld be written:
(not (eq (fn1 arg2 arg2) null))
and reserve when for actual control-flow matters, rather than boolean
operations.
Date: Fri, 14 Jan 2011 11:42:16 -0500
From: Daniel Weinreb
Subject: [pro] Style issue about predicates
If you have a function that is a predicate, in the sense that
the
Daniel Weinreb writes:
>
> If you have a function that is a predicate, in the sense that
> the function's contract says that its value should be interpreted
> as being either false or true, do you think it's better to code
> it so that it always returns "t" for the true case?
>
I use '-p' and
On Fri, Jan 14, 2011 at 8:42 AM, Daniel Weinreb wrote:
> If you have a function that is a predicate, in the sense that
> the function's contract says that its value should be interpreted
> as being either false or true, do you think it's better to code
> it so that it always returns "t" for the tr
No, it should just return "true" (non-nil). It shouldn't guarantee T as a
value, nor any particular "true" value.
It's wrong for the programmer using a predicate to rely on the "true" value
being any particular value, including T.
Therefore, doing the (when ... t) thing just makes it return on
On Jan 14, 2011, at 11:42 AM, Daniel Weinreb wrote:
> If you have a function that is a predicate, in the sense that
> the function's contract says that its value should be interpreted
> as being either false or true, do you think it's better to code
> it so that it always returns "t" for the true c
From: Edi Weitz
Date: Fri, 14 Jan 2011 17:59:52 +0100
Cc: Sergey Vasilyev ,
Common Lisp Professionals
There are lots of functions in the standard which are predicates in
that they return generalized booleans but on the other hand return
something "useful" if the resu
There are lots of functions in the standard which are predicates in
that they return generalized booleans but on the other hand return
something "useful" if the result is not NIL, e.g. MEMBER or STRING<.
I think this is good practice, i.e. return something other than T in
case this might make more
If you have a function that is a predicate, in the sense that
the function's contract says that its value should be interpreted
as being either false or true, do you think it's better to code
it so that it always returns "t" for the true case?
Since Common Lisp is quite clear that when a value
is
13 matches
Mail list logo
