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 being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t.
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know.
All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like:
(defun ... ... (when (fn1 arg2 arg2) t))
It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate.
Is this good, bad, don't care, depends on the circumstance?
-- Dan
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 sense. Of course, this should then be documented in the predicate's contract and thus should be OK to use by the caller.
On Fri, Jan 14, 2011 at 5:42 PM, Daniel Weinreb dlw@itasoftware.com 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 case?
Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t.
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know.
All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like:
(defun ... ... (when (fn1 arg2 arg2) t))
It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate.
Is this good, bad, don't care, depends on the circumstance?
-- Dan
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
From: Edi Weitz edi@weitz.de Date: Fri, 14 Jan 2011 17:59:52 +0100 Cc: Sergey Vasilyev sergey@itasoftware.com, Common Lisp Professionals pro@common-lisp.net
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<.
And some of them might also end in -p
(digit-char-p)
-nick
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 one particular true value (T) that the programmer should not rely upon anyhow.
-Mark 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 case?
Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t.
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know.
All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like:
(defun ... ... (when (fn1 arg2 arg2) t))
It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate.
Is this good, bad, don't care, depends on the circumstance?
-- Dan
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
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 case?
I am distracted by the need to write:
(defun truthy (x) (not (not x)))
or if you's is the kind of organization that builds a development v.s. a production version...
(defmacro truthy (x) #+dev `(not (not ,x)) #-dev `,x)
It would be nice to have a code base that is more truthy.
On Fri, Jan 14, 2011 at 8:42 AM, Daniel Weinreb dlw@itasoftware.com 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 case?
I've never bothered.
Of course I'm also one of these people who routinely use AND and OR to return non-boolean values, which apparently a lot of people dislike (it's specifically contravened in Peter Norvig's style guide, for instance).
BTW I prefer the trailing question mark convention over "-p". Scheme uses the question mark, but I'm not sure the convention originated there -- I think it may actually have started in the InterLisp community. Does anyone know?
-- Scott
Daniel Weinreb <dlw@...> 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 '?' depending on the function name aesthetics (generally not both in the same function name). These return whatever object is being tested, for example physics-hook-p will return a function or NIL otherwise.
How about defining defsetf for predicates?
-Luke
In article 4D307CE8.1000208@itasoftware.com, Daniel Weinreb dlw@itasoftware.com 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 case?
Since Common Lisp is quite clear that when a value is being considered in the context of being true/false, nil means false and everything else means true. So from a language point of view, even considering the "intent" of the definition and not just the spec, there is no need to return t.
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context. This should be in the doc string, or at least in a comment, and the function name should end in "p" (or always "-p" but let's please not get into that in this email thread). So the caller should know.
All that said, it's possible that a programmer will fail to heed the contract, simply look at the code, and take advantage of the returned value in more than true/false context. If you want to prevent that, you can do something like:
(defun ... ... (when (fn1 arg2 arg2) t))
It seems that it might depend on the circumstance: how likely do you think it is that a programmer would commit such a mistake? The more potentially valuable the returned value is, the more likely. On the other hand, if it's so valuable, maybe you should actually make that part of the contract rather than making the function have the contract of a predicate.
Is this good, bad, don't care, depends on the circumstance?
-- Dan
I think it's good style to make predicates return T (except for the rare case Edi cited where the return value could also legitimately be made sense of differently.)
Returning another value that the user might see when playing at the REPL seems like leaking internal decomposition to me.
I also prefer to use (AND (FOO ...) T) rather than WHEN in that case because WHEN is a control-flow construct but this case is about data normalization, and thus I consider AND more appropriate.
-T.
......................., 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 assume 't' is the only truth) in case I find a way for returning a useful other-than-nil value in future. OTOH, I think this (using a generalized-boolean rather than boolean) will mesh well with CL style (most of it).
In case of 'nil' as a useful value, I'll return multiple values similar to gethash.
also I try (most of the time if possible) to adhere to the definitions in the glossary of CLHS. in this case it defines a predicate as a function returning generalized-boolean as its first value. (I do this in part so that CLHS wil act as a part in documenting the terms used in my own documentation like doc strings and others, in other words having a common glossary to use)
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context.
I'll use the followings (from CLHS glossary) in documenting the return value(s) Boolean for t and nil symbols Generalized Boolean for nil and others-are-true
(defun ... ... (when (fn1 arg2 arg2) t))
or use
(defun truep (object) (not (not object)) ;; 'not' is specified to return either nil or t only
(defun ... .... .... (truep (predic1 arg1 arg2))
;; both name and implementation on comp.lang.lisp from Kent (~ around 13 years ago)
Regards,
Ala'a Mohammad.
-
Ala'a Mohammad -
Ben Hyde -
Daniel Weinreb -
Edi Weitz -
Luke Crook -
Mark H. David -
Nick Levine -
Scott L. Burson -
Tobias C Rittweiler