I needed a functional version of the AND and OR connectives, instead
of the usual macros, so that I could pass them as functional arguments
(something you can't do of course with macros). So I devised a
personal solution for Scheme, but I've always been heavily biased
towards Common Lisp, so I quickly translated it. But then I came
across Peter Seibel's FAQ, and I discovered yet another way.
So, briefly, here are a couple of ways of achieving this:
(defun andf (&rest lst)
(cond ((null lst) t)
((not (car lst)) nil)
(t (apply #'andf (cdr lst)))))
(defun orf (&rest lst)
(cond ((null lst) nil)
((car lst) t)
(t (apply #'orf (cdr lst)))))
or, alternatively:
(defun andf (&rest lst)
(every #'identity lst))
(defun orf (&rest lst)
(some #'identity lst))
Please let me know what you think.
···········@gmail.com wrote:
> I needed a functional version of the AND and OR connectives, instead
> of the usual macros, so that I could pass them as functional arguments
> (something you can't do of course with macros). So I devised a
> personal solution for Scheme, but I've always been heavily biased
> towards Common Lisp, so I quickly translated it. But then I came
> across Peter Seibel's FAQ, and I discovered yet another way.
>
> So, briefly, here are a couple of ways of achieving this:
>
> (defun andf (&rest lst)
The name had me trying to figure out how you would be setf-ing the first
value of the list, which you did not have to call lst.
So, you are content to have completely different behavior, in that each
form will be evaluated even if, say in the case of andf, the first
evaluates to nil?
kt
> (cond ((null lst) t)
> ((not (car lst)) nil)
> (t (apply #'andf (cdr lst)))))
>
> (defun orf (&rest lst)
> (cond ((null lst) nil)
> ((car lst) t)
> (t (apply #'orf (cdr lst)))))
>
> or, alternatively:
>
> (defun andf (&rest lst)
> (every #'identity lst))
>
> (defun orf (&rest lst)
> (some #'identity lst))
>
> Please let me know what you think.
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 1, 10:50 am, Ken Tilton <···········@optonline.net> wrote:
> ···········@gmail.com wrote:
> > I needed a functional version of the AND and OR connectives, instead
> > of the usual macros, so that I could pass them as functional arguments
> > (something you can't do of course with macros). So I devised a
> > personal solution for Scheme, but I've always been heavily biased
> > towards Common Lisp, so I quickly translated it. But then I came
> > across Peter Seibel's FAQ, and I discovered yet another way.
>
> > So, briefly, here are a couple of ways of achieving this:
>
> > (defun andf (&rest lst)
>
> The name had me trying to figure out how you would be setf-ing the first
> value of the list, which you did not have to call lst.
>
> So, you are content to have completely different behavior, in that each
> form will be evaluated even if, say in the case of andf, the first
> evaluates to nil?
>
> kt
>
>
>
> > (cond ((null lst) t)
> > ((not (car lst)) nil)
> > (t (apply #'andf (cdr lst)))))
>
> > (defun orf (&rest lst)
> > (cond ((null lst) nil)
> > ((car lst) t)
> > (t (apply #'orf (cdr lst)))))
>
> > or, alternatively:
>
> > (defun andf (&rest lst)
> > (every #'identity lst))
>
> > (defun orf (&rest lst)
> > (some #'identity lst))
>
> > Please let me know what you think.
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Of course, I'm very pleased to tell you the truth. You see, I don't
care if the argument list gets evaluated or not, because these
functions are meant to be used mathematically as pure "logic"
functions with values T and NIL (which evaluate to themselves by the
way, so there's no issue to begin with). As you can see from my
previous post, I also wanted these connectives in the form of
functions instead of macros, so that I can pass them around as
functional arguments (higher-order functional porgramming).
I am not interested in AND and OR from a "conditional" point of view,
but what I need is pure logical "functions" which work especially with
TRUE and FALSE values (T and NIL).
From: Kent M Pitman
Subject: Re: ANDF, ORF functions instead of macros
Date:
Message-ID: <u8x4eb6pv.fsf@nhplace.com>
···········@gmail.com writes:
> I am not interested in AND and OR from a "conditional" point of view,
> but what I need is pure logical "functions" which work especially with
> TRUE and FALSE values (T and NIL).
Make sure you read about the difference between a "boolean" and a
"generalized boolean". Many of the CL predicates return generalized
booleans, not booleans. This was a source of some hassle in one of
the public review/comment period of one of the draft versions of ANSI
CL, when some well-known people in the theorem proving world grumbled
that I had introduced generalized booleans and that it was messing up
the ability to do
(eq (...some-predicate...) (...some-other-predicate...))
to compare truth values. [McCarthy got dragged into this discussion as
well I don't recall whether McCarthy agreed with the concern, though I
may have the mail about that. ... Hmm, it might have been Boyer
and/or Moore (of theorem proving fame), but I'm not sure ... does anyone
remember? It's surely a matter of record. My personal records of this
are in a box in my garage and I'm not up to sifting.]
In fact, as I believe the public review response was able to document,
I didn't change the semantics, I only changed the wording to make the
existing semantics apparent. Steele [and the original informal CL
design committee, on which I was a technical contributor, but not a
prominent one] had, in CLTL, made this change from MACLISP and earlier
dialects, that had always returned T. [There were technical reasons
in MACLISP why returning generalized booleans was bad efficiency-wise,
so it had never been considered as an alternative. Thos restrictions
became less of an issue in later dialects, which is why this practice
became more common.] My purpose in changing the terminology was to
make ANSI more easier to figure out than CLTL, and I took it as a
major personal victory that this change in terminology caused people
to realize things that had been true about the language and gone
unrealized before. :)
So we didn't change it, and as a result, you probably want to introduce
your own
SAME-BOOLEAN-VALUE predicate so you can do
(same-boolean-value (...some-predicate...) (...some-other-predicate...))
or else you want a coercer from generalized boolean values to
boolean values, such as a BOOLEAN or TRUE? function that returns only a
strict boolean, so you can do:
(eq (true? (...some-predicate...)) (true? (...some-other-predicate...)))
+ Kent M Pitman <······@nhplace.com>:
> So we didn't change it, and as a result, you probably want to introduce
> your own
> SAME-BOOLEAN-VALUE predicate so you can do
> (same-boolean-value (...some-predicate...) (...some-other-predicate...))
> or else you want a coercer from generalized boolean values to
> boolean values, such as a BOOLEAN or TRUE? function that returns only a
> strict boolean, so you can do:
> (eq (true? (...some-predicate...)) (true? (...some-other-predicate...)))
I suppose one could write that simply as
(eq (not (...some-predicate...)) (not (...some-other-predicate...)))
or is that too obfuscated?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: Kent M Pitman
Subject: Re: ANDF, ORF functions instead of macros
Date:
Message-ID: <uir3i9ixh.fsf@nhplace.com>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Kent M Pitman <······@nhplace.com>:
>
> > So we didn't change it, and as a result, you probably want to introduce
> > your own
> > SAME-BOOLEAN-VALUE predicate so you can do
> > (same-boolean-value (...some-predicate...) (...some-other-predicate...))
> > or else you want a coercer from generalized boolean values to
> > boolean values, such as a BOOLEAN or TRUE? function that returns only a
> > strict boolean, so you can do:
> > (eq (true? (...some-predicate...)) (true? (...some-other-predicate...)))
>
> I suppose one could write that simply as
> (eq (not (...some-predicate...)) (not (...some-other-predicate...)))
> or is that too obfuscated?
Yep, that's been suggested before too and I should have mentioned it,
so I'm glad you did. I'm sure there are people that do it that way.
Personally, I think it lacks in perspicuity but saves having one extra
definition. (Note that such a definition could be made INLINE, in
most cases eliminating the function call overhead.) The key thing is
that you have to know to do it.
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| ...you probably want to introduce your own
| SAME-BOOLEAN-VALUE predicate so you can do
| (same-boolean-value (...some-predicate...) (...some-other-predicate...))
| or else you want a coercer from generalized boolean values to
| boolean values, such as a BOOLEAN or TRUE? function that returns only a
| strict boolean, so you can do:
| (eq (true? (...some-predicate...)) (true? (...some-other-predicate...)))
+---------------
I call such a coercion simply TRUTH, e.g.:
(eq (truth (...some-predicate...)) (truth (...some-other-predicate...)))
One relatively cheap definition:
(define truth (generalized-boolean)
(not (not generalized-boolean)))
Another:
(define truth (generalized-boolean)
(if generalized-boolean t nil))
Which is cheaper may depend on your compiler and/or the amount of
work you put into writing an associated compiler macro for it... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: ANDF, ORF functions instead of macros
Date:
Message-ID: <ud4tqb7ho.fsf@nhplace.com>
Ken Tilton <···········@optonline.net> writes:
> ···········@gmail.com wrote:
> > I needed a functional version of the AND and OR connectives, [...]
> > (defun andf (&rest lst)
>
> The name had me trying to figure out how you would be setf-ing the
> first value of the list, which you did not have to call lst.
Me too. Somewhere along the lines, perhaps due to something in Maclisp,
I picked up the practice of using * prefixed on a function for this.
e.g., *and and *or.
Although in these particular cases, I don't tend to use that convention
because descriptive names like all-true and some-true (or one-of) tend
to suit me better. If you're only using it for boolean value, as in
all-true, I recommend
(and (every #'identity lst) t)
or
(if (every #'identity lst) t nil)
by the way. Although the name SOME-OF works for non-boolean results,
ALL-OF would only be good for me with a non-boolean result if you were
going to return a list of all the true values in that case, which most
people would say they didn't want.
> So, you are content to have completely different behavior, in that
> each form will be evaluated even if, say in the case of andf, the
> first evaluates to nil?
Evaluates? There's no evaluation in these. The args are (or are not)
evaluated before this function ever sees them.
In article
<····································@e4g2000hsg.googlegroups.com>,
···········@gmail.com wrote:
> I needed a functional version of the AND and OR connectives, instead
> of the usual macros, so that I could pass them as functional arguments
> (something you can't do of course with macros).
CL already has this built in. They're called EVERY and SOME.
--
Barry Margolin
Arlington, MA
From: Kent M Pitman
Subject: Re: ANDF, ORF functions instead of macros
Date:
Message-ID: <u4pf2b6i8.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:
> In article
> <····································@e4g2000hsg.googlegroups.com>,
> ···········@gmail.com wrote:
>
> > I needed a functional version of the AND and OR connectives, instead
> > of the usual macros, so that I could pass them as functional arguments
> > (something you can't do of course with macros).
>
> CL already has this built in. They're called EVERY and SOME.
I took it that for functional composition reasons he didn't want to use
the first argument.
For efficiency reasons, he may not want to do this suggestion, but for
just pure elegance/abstraction purposes, a CURRY function might be
what he wants. Then he could use (CURRY #'EVERY #'IDENTITY).
In practice, I think things like this are probably things you often want
to special-case to avoid computational overhead of processing extra args.
[But see my recent comments in the discussion of clisp
http://groups.google.com/group/comp.lang.lisp/msg/992bf474e95b0edf?dmode=source
about the never-ending and somewhat pointless quest to get tiny bits
of speed.]
···········@gmail.com wrote:
> I needed a functional version of the AND and OR connectives, instead
> of the usual macros, so that I could pass them as functional arguments
> (something you can't do of course with macros). So I devised a
> personal solution for Scheme, but I've always been heavily biased
> towards Common Lisp, so I quickly translated it. But then I came
> across Peter Seibel's FAQ, and I discovered yet another way.
>
> So, briefly, here are a couple of ways of achieving this:
>
> (defun andf (&rest lst)
> (cond ((null lst) t)
> ((not (car lst)) nil)
> (t (apply #'andf (cdr lst)))))
>
> (defun orf (&rest lst)
> (cond ((null lst) nil)
> ((car lst) t)
> (t (apply #'orf (cdr lst)))))
>
> or, alternatively:
>
> (defun andf (&rest lst)
> (every #'identity lst))
>
> (defun orf (&rest lst)
> (some #'identity lst))
>
> Please let me know what you think.
In Common Lisp, the naming convention xyzf or something-something-f is
typically used to indicate a setf-style macro (like incf, decf and - er
- push). So by using that naming convention here for a completely
different purpose, you are likely to confuse readers of your code.
The recursive version above is very Schemish - you're using Schemy names
(why 'lst', why not just 'list'?). Also, in the general case, it is not
guaranteed that tail recursions are converted into jumps, so you may be
consuming more stack space than necessary.
The (some #'identity bla) and (every #'identity blubb) idioms are so
simple to use that I doubt that anyone would every define something like
your andf or orf.
And here is some code from the 'do everything with loop' department:
(defun and-fun (&rest list)
(declare (dynamic-extent list)) ;;; nice to save heap space
(loop for truth in list always truth))
(defun or-fun (&rest list)
(declare (dynamic-extent list))
(loop for truth-value in list thereis truth))
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Dec 1, 12:10 pm, Pascal Costanza <····@p-cos.net> wrote:
> ···········@gmail.com wrote:
> > I needed a functional version of the AND and OR connectives, instead
> > of the usual macros, so that I could pass them as functional arguments
> > (something you can't do of course with macros). So I devised a
> > personal solution for Scheme, but I've always been heavily biased
> > towards Common Lisp, so I quickly translated it. But then I came
> > across Peter Seibel's FAQ, and I discovered yet another way.
>
> > So, briefly, here are a couple of ways of achieving this:
>
> > (defun andf (&rest lst)
> > (cond ((null lst) t)
> > ((not (car lst)) nil)
> > (t (apply #'andf (cdr lst)))))
>
> > (defun orf (&rest lst)
> > (cond ((null lst) nil)
> > ((car lst) t)
> > (t (apply #'orf (cdr lst)))))
>
> > or, alternatively:
>
> > (defun andf (&rest lst)
> > (every #'identity lst))
>
> > (defun orf (&rest lst)
> > (some #'identity lst))
>
> > Please let me know what you think.
>
> In Common Lisp, the naming convention xyzf or something-something-f is
> typically used to indicate a setf-style macro (like incf, decf and - er
> - push). So by using that naming convention here for a completely
> different purpose, you are likely to confuse readers of your code.
>
> The recursive version above is very Schemish - you're using Schemy names
> (why 'lst', why not just 'list'?). Also, in the general case, it is not
> guaranteed that tail recursions are converted into jumps, so you may be
> consuming more stack space than necessary.
>
> The (some #'identity bla) and (every #'identity blubb) idioms are so
> simple to use that I doubt that anyone would every define something like
> your andf or orf.
>
> And here is some code from the 'do everything with loop' department:
>
> (defun and-fun (&rest list)
> (declare (dynamic-extent list)) ;;; nice to save heap space
> (loop for truth in list always truth))
>
> (defun or-fun (&rest list)
> (declare (dynamic-extent list))
> (loop for truth-value in list thereis truth))
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
I'm sorry but I think you made a mistake in your or-fun. Probably what
you meant was:
(defun or-fun (&rest list)
(declare (dynamic-extent list))
(loop for truth in list thereis truth))
Anyway, I noticed you guys are VERY fussy when it comes to names and
labels! OK, as I initially specified, I first wrote the code in Scheme
even though I usually prefer Common Lisp. I quickly converted it
without worrying too much about the names. I am perfectly aware that
Common Lisp is a Lisp-2 and Scheme a Lisp-1, and so that I could have
very well changed "lst" into "list". But I didn't do it. So what? Is
there any need for EVERYBODY to point this out repeatedly? I got the
message already.
Mr. Costanza I thank you very much for showing me yet another method
for writing AND and OR functions through the use of LOOP, ALWAYS, and
THEREIS. I don't quite actually understand your objection though
regarding my definitions of the same functions with EVERY and SOME. I
don't see what's so wrong or bad about it. I couldn't use EVERY or
SOME directly as logical functional arguments because they require an
extra argument (in my case #'IDENTITY) so I wrapped them up
accordingly. What's so strange about that?
Finally thanks to everyone for their considerations and suggestions.
To make you all happy I've rewritten the two notorious functions in a
more acceptable Common Lisp (Lisp-2) style. Please forgive me for
being so terribly and lightheartedly Schemish. I didn't mean to offend
anyone!
(defun and-fun (&rest list)
(cond ((null list) t)
((not (car list)) nil)
(t (apply #'and-fun (cdr list)))))
(defun or-fun (&rest list)
(cond ((null list) nil)
((car list) t)
(t (apply #'or-fun (cdr list)))))
or, alternatively:
(defun and-fun (&rest list)
(every #'identity list))
(defun or-fun (&rest list)
(some #'identity list))
···········@gmail.com wrote:
> I'm sorry but I think you made a mistake in your or-fun. Probably what
> you meant was:
>
> (defun or-fun (&rest list)
> (declare (dynamic-extent list))
> (loop for truth in list thereis truth))
Indeed.
> Anyway, I noticed you guys are VERY fussy when it comes to names and
> labels! OK, as I initially specified, I first wrote the code in Scheme
> even though I usually prefer Common Lisp. I quickly converted it
> without worrying too much about the names. I am perfectly aware that
> Common Lisp is a Lisp-2 and Scheme a Lisp-1, and so that I could have
> very well changed "lst" into "list". But I didn't do it. So what? Is
> there any need for EVERYBODY to point this out repeatedly? I got the
> message already.
There is no reason to feel attacked. A response in usenet is not
necessarily a direct response addressed at your personally (direct email
would be much easier in that regard), but rather a 'broadcast' response
that is supposed to be useful for other readers as well.
> Mr. Costanza I thank you very much for showing me yet another method
> for writing AND and OR functions through the use of LOOP, ALWAYS, and
> THEREIS. I don't quite actually understand your objection though
> regarding my definitions of the same functions with EVERY and SOME. I
> don't see what's so wrong or bad about it. I couldn't use EVERY or
> SOME directly as logical functional arguments because they require an
> extra argument (in my case #'IDENTITY) so I wrapped them up
> accordingly. What's so strange about that?
Nothing. I didn't know that you have this use case in mind. I haven't
seen it yet, and for the other cases, a direct invocation of 'every or
'some seems sufficient to me.
But what do I know... ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
···········@gmail.com wrote:
> Anyway, I noticed you guys are VERY fussy when it comes to names and
> labels!
Yeah, what is wrong with us? In four characters you managed to mislead
the reader two ways, first that your creation set state, second in re
how the arguments would be evaluated.
You guy REALLY know how to write crappy code!
Amateurs like me have monkeys typing function names at random, but you!
You go the extra mile or ten to come up with names that actively mislead
the reader, which is usually only yourself thank the frickin lord.
Listen, pal, you clearly have all the answers, next time you churn out
some of these priceless gems, maybe keep them to yourself?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 2, 12:21 am, Ken Tilton <···········@optonline.net> wrote:
> ···········@gmail.com wrote:
> > Anyway, I noticed you guys are VERY fussy when it comes to names and
> > labels!
>
> Yeah, what is wrong with us? In four characters you managed to mislead
> the reader two ways, first that your creation set state, second in re
> how the arguments would be evaluated.
>
> You guy REALLY know how to write crappy code!
>
> Amateurs like me have monkeys typing function names at random, but you!
> You go the extra mile or ten to come up with names that actively mislead
> the reader, which is usually only yourself thank the frickin lord.
>
> Listen, pal, you clearly have all the answers, next time you churn out
> some of these priceless gems, maybe keep them to yourself?
>
> kt
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Man, are you the nervous type! Look, hey no problem. I wasn't trying
to be a wise guy or something like that. All I was trying to say is
that, after the first or second post emphasizing the label business I
thought one could concentrate only on the "semantics" of the code. It
was just a few lines long so c'mon don't tell me that a simple small
function like that could really confuse anybody as to its
functionality or purpose! Let me repeat that, just a "few lines of
code" ... it wasn't any huge complicated application or library, was
it? Just a little thing to think about, that's all.
I already apologized for having written perhaps too quickly converting
the Scheme code, so that a schemish kind of style was still apparent.
I even rewrote the thing in an "acceptable" style in a subsequent
post. But honestly, I couldn't have imagined it was such a big
deal ... and I thought the "Scheme guys" were the "purists"! By the
way, Lisp is supposed to be a family of languages, so what's wrong
with cutting some slack even if it was written in a schemish style?
Finally, I don't think I know it all ... far from it, I don't know
anything and I like to learn and share ideas with people, including
you if you're up to it. I don't think there's anything wrong with
expressing an idea, or even a small remark with regard to a specific
attitude, otherwise what's the point in communicating?
Take care, and have a happy and serene life.
···········@gmail.com wrote:
> On Dec 2, 12:21 am, Ken Tilton <···········@optonline.net> wrote:
>
>>···········@gmail.com wrote:
>>
>>>Anyway, I noticed you guys are VERY fussy when it comes to names and
>>>labels!
>>
>>Yeah, what is wrong with us? In four characters you managed to mislead
>>the reader two ways, first that your creation set state, second in re
>>how the arguments would be evaluated.
>>
>>You guy REALLY know how to write crappy code!
>>
>>Amateurs like me have monkeys typing function names at random, but you!
>>You go the extra mile or ten to come up with names that actively mislead
>>the reader, which is usually only yourself thank the frickin lord.
>>
>>Listen, pal, you clearly have all the answers, next time you churn out
>>some of these priceless gems, maybe keep them to yourself?
>>
>>kt
>>
>>--http://www.theoryyalgebra.com/
>>
>>"In the morning, hear the Way;
>> in the evening, die content!"
>> -- Confucius
>
>
> Man, are you the nervous type!
Now how the hell did I know you were going to help us with other
problems we have? Man, you are a godsend tot his group!
Folks, please relay to me the future brilliance of this clown, for some
reason I do not think my newsreader will be letting his genius thru.
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 2, 11:12 pm, Ken Tilton <···········@optonline.net> wrote:
> ···········@gmail.com wrote:
> > On Dec 2, 12:21 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>···········@gmail.com wrote:
>
> >>>Anyway, I noticed you guys are VERY fussy when it comes to names and
> >>>labels!
>
> >>Yeah, what is wrong with us? In four characters you managed to mislead
> >>the reader two ways, first that your creation set state, second in re
> >>how the arguments would be evaluated.
>
> >>You guy REALLY know how to write crappy code!
>
> >>Amateurs like me have monkeys typing function names at random, but you!
> >>You go the extra mile or ten to come up with names that actively mislead
> >>the reader, which is usually only yourself thank the frickin lord.
>
> >>Listen, pal, you clearly have all the answers, next time you churn out
> >>some of these priceless gems, maybe keep them to yourself?
>
> >>kt
>
> >>--http://www.theoryyalgebra.com/
>
> >>"In the morning, hear the Way;
> >> in the evening, die content!"
> >> -- Confucius
>
> > Man, are you the nervous type!
>
> Now how the hell did I know you were going to help us with other
> problems we have? Man, you are a godsend tot his group!
>
> Folks, please relay to me the future brilliance of this clown, for some
> reason I do not think my newsreader will be letting his genius thru.
>
> kzo
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
No comment. I give up.
···········@gmail.com writes:
> I needed a functional version of the AND and OR connectives, instead
> of the usual macros, so that I could pass them as functional arguments
> (something you can't do of course with macros). So I devised a
> personal solution for Scheme, but I've always been heavily biased
> towards Common Lisp, so I quickly translated it. But then I came
> across Peter Seibel's FAQ, and I discovered yet another way.
>
> So, briefly, here are a couple of ways of achieving this:
>
> (defun andf (&rest lst)
> (cond ((null lst) t)
> ((not (car lst)) nil)
> (t (apply #'andf (cdr lst)))))
>
> (defun orf (&rest lst)
> (cond ((null lst) nil)
> ((car lst) t)
> (t (apply #'orf (cdr lst)))))
>
> or, alternatively:
>
> (defun andf (&rest lst)
> (every #'identity lst))
>
> (defun orf (&rest lst)
> (some #'identity lst))
>
> Please let me know what you think.
(defun boolean-and (&rest args)
(reduce #'(lambda(x y)(and x y))
args
:initial-value t))
(defun boolean-or(&rest args)
(reduce #'(lambda(x y)(or x y))
args
:initial-value nil))
isn't quite as neat, but arises in two natural steps.
1) in the common case of two arguments the function is
(lambda(x y) (and x y))
2) REDUCE is the standard way of getting from a two argument
function to a variable number of arguments
Thinking about the recursive versions, when writing
predicate functions, it is often nice to write them using
AND and OR rather than COND
(defun boolean-and (&rest args)
(or (null args)
(and (first args)
(apply #'boolean-and (rest args)))))
(defun boolean-or (&rest args)
(and args
(or (first args)
(apply #'boolean-and (rest args)))))
What do you think?
Alan Crowe
Edinburgh
Scotland
On Dec 1, 10:21 pm, Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
> ···········@gmail.com writes:
> > I needed a functional version of the AND and OR connectives, instead
> > of the usual macros, so that I could pass them as functional arguments
> > (something you can't do of course with macros). So I devised a
> > personal solution for Scheme, but I've always been heavily biased
> > towards Common Lisp, so I quickly translated it. But then I came
> > across Peter Seibel's FAQ, and I discovered yet another way.
>
> > So, briefly, here are a couple of ways of achieving this:
>
> > (defun andf (&rest lst)
> > (cond ((null lst) t)
> > ((not (car lst)) nil)
> > (t (apply #'andf (cdr lst)))))
>
> > (defun orf (&rest lst)
> > (cond ((null lst) nil)
> > ((car lst) t)
> > (t (apply #'orf (cdr lst)))))
>
> > or, alternatively:
>
> > (defun andf (&rest lst)
> > (every #'identity lst))
>
> > (defun orf (&rest lst)
> > (some #'identity lst))
>
> > Please let me know what you think.
>
> (defun boolean-and (&rest args)
> (reduce #'(lambda(x y)(and x y))
> args
> :initial-value t))
>
> (defun boolean-or(&rest args)
> (reduce #'(lambda(x y)(or x y))
> args
> :initial-value nil))
>
> isn't quite as neat, but arises in two natural steps.
>
> 1) in the common case of two arguments the function is
> (lambda(x y) (and x y))
>
> 2) REDUCE is the standard way of getting from a two argument
> function to a variable number of arguments
>
> Thinking about the recursive versions, when writing
> predicate functions, it is often nice to write them using
> AND and OR rather than COND
>
> (defun boolean-and (&rest args)
> (or (null args)
> (and (first args)
> (apply #'boolean-and (rest args)))))
>
> (defun boolean-or (&rest args)
> (and args
> (or (first args)
> (apply #'boolean-and (rest args)))))
>
> What do you think?
>
> Alan Crowe
> Edinburgh
> Scotland
Very nice. I like this solution a lot. Thank you so much for your
contribution and also for showing me how to use the AND and OR
conditionals as a replacement for COND in these circumstances.