Maybe I'm missing something, but I don't see why (apply #'or '(t nil t nil))
shouldn't work. What am I missing?
Thanks in advance for any help,
David Yang
······@cs.columbia.edu
Script started on Fri Feb 15 01:40:19 1991
$ lisp
sh: lisp: not found
$ ../lisp
;;;
;;; Sun Common Lisp, Development Environment 3.0.1, 27 October 1988
;;; Sun-4 Version for SunOS 4.0
;;;
;;; Copyright (c) 1985, 1986, 1987, 1988 by Sun Microsystems, Inc., All Rights Reserved
;;; Copyright (c) 1985, 1986, 1987, 1988 by Lucid, Inc., All Rights Reserved
;;;
;;; This software product contains confidential and trade secret
;;; information belonging to Sun Microsystems. It may not be copied
;;; for any reason other than for archival and backup purposes.
> (apply #'or '(t nil t nil))
>>Error: OR called with 4 arguments, but only 2 arguments are allowed
OR:
Required arg 0 (FORM): T
Required arg 1 (ENVIRONMENT): NIL
:C 0: Ignore extra arguments
:A 1: Abort to Lisp Top Level
-> (apply #'+ '(1 2 3 4))
10
-> (quit)
$
script done on Fri Feb 15 01:41:04 1991
From: Eliot Handelman
Subject: Re: Problem with (apply #'or <list>)? (cl 3.0.1)
Date:
Message-ID: <6297@idunno.Princeton.EDU>
In article <······················@cs.columbia.edu> ······@division.columbia.edu (David Yang) writes:
;Maybe I'm missing something, but I don't see why (apply #'or '(t nil t nil))
;shouldn't work. What am I missing?
CLtL II, pg 145 (from I): "it is illegal for the symbol to be the name
of a macro or special form."
You can use SOME to do the same thing like this:
(apply #'some #'identity (list '(t nil t nil)))
But that's not very idiomatic, since (some #'identity '(t nil t nil))
is equivalent. In short, you probably don't need APPLY here at all.
OR is a macro and therefore can't be used as an argument to APPLY.
--
Peter L. DeWolf
Motorola Cambridge Research Center
···@mcrc.mot.com -or- ···@abp.lcs.mit.edu
Thanks for all the helpful and patient answers;
here's one with an alternative.
David
From: Andrew Philpot <·······@ptolemy.arc.nasa.gov>
;
; As someone has no doubt already told you (but hey what's another
; redundant message):
;
; OR is usually a macro, (or I think sometimes a special form) and thus
; cannot be applied.
;
; If you want to map across a list of (assumed) boolean values,
; returning the first one which is not NIL, or NIL if they all are NIL,
; try:
;
; (some #'identity <list of booleans>)
;
; for example
;
; > (some #'identity '(t nil t nil))
; T
;
; > (some #'identity '(nil nil () 5 t nil))
; 5
;
; > (some #'identity '(nil nil nil nil))
; NIL
;
; etc.
;
; Also see EVERY, NOTANY, NOTEVERY.
;
; << Andrew >>
;
From: Jeff Dalton
Subject: Re: Problem with (apply #'or <list>)? (cl 3.0.1)
Date:
Message-ID: <4147@skye.ed.ac.uk>
This seems to be a "frequently asked question".
There's a short answer ("OR is a macro, and macros can't be applied")
and a long one (an explanation of why macros such as OR can't be applied).
The long answer is sometimes needed because (1) in some Lisps apply
could be used on macros, and (2) because of (1) or for some other
reason, some people expect it to work, at least for the macros that
are enough like functions.
(I don't want to type in the long answer now, because it's long and
because it's been done before and because this time maybe no one needs
it. But if anyone every draws up a FAQ list, they might want to bear
this in mind.)
From: ····@ccvax.ucd.ie
Subject: Re: Problem with (apply #'or <list>)? (cl 3.0.1)
Date:
Message-ID: <47946.27c2d8d3@ccvax.ucd.ie>
In article <······················@cs.columbia.edu>, (David Yang) writes:
> Maybe I'm missing something, but I don't see why (apply #'or '(t nil t nil))
> shouldn't work. What am I missing?
>
I agree that it seems odd that special forms can't be APPLYed or FUNCALLed,
however in your particular example, what you are missing are the functions
EVERY, SOME, NOTANY and NOTEVERY, (CLtL, 1st Ed, page 250).
(apply #'or list-of-values) == (some list-of-values)
(apply #'and list-of-values) == (every list-of-values)
As for the reason why special forms cannot be FUNCALLed or APPLYe, I reckon
it has to do with the fact that it is unknown which (if any) args are to
be evaluated or not.
If SOME or EVERY won't do the job, you could use
(eval (cons 'or list-of-values))....
Eamonn Webster ····@ccvax.ucd.ie
Department of Computer Science ····@ccvax.bitnet
University College Dublin
Belfield
Dublin 4
Ireland
Phone +353-1-693244 ext 2484 Fax: +353-1-697262
In article <··············@ccvax.ucd.ie> ····@ccvax.ucd.ie writes:
As for the reason why special forms cannot be FUNCALLed or APPLYe, I reckon
it has to do with the fact that it is unknown which (if any) args are to
be evaluated or not.
Macros and special forms can be thought of extensions to the compiler.
Once you have compiled code, the macros don't need to exist. In contrast,
functions are objects, whic exist at run time. FUNCALL and APPLY operate
on these run-time objects.
--
····@ccvax.ucd.ie writes:
>I agree that it seems odd that special forms can't be APPLYed or FUNCALLed,
>however in your particular example, what you are missing are the functions
>EVERY, SOME, NOTANY and NOTEVERY, (CLtL, 1st Ed, page 250).
>
> (apply #'or list-of-values) == (some list-of-values)
> (apply #'and list-of-values) == (every list-of-values)
EVERY, SOME, etc., are exactly the kind of "kitchen sink" functions
that I object to in Common Lisp. They provide no additional
functionality to the language, are semantically confusing, and make
reading code difficult.
A language that has a 1000 built-in functions (constructs) is doomed.
People don't have the cognitive mechanisms to deal with that number
and variety of mechanisms. The result is that each person uses their
own personal subset of the language, and a Tower of Babel results.
Far from being "common", Common Lisp is doomed to be uncommon.
-- Scott Turner
In article <·····················@aero.org> ···@aero.org (Scott Turner) writes:
>EVERY, SOME, etc., are exactly the kind of "kitchen sink" functions
>that I object to in Common Lisp. They provide no additional
>functionality to the language, are semantically confusing, and make
>reading code difficult.
>
>A language that has a 1000 built-in functions (constructs) is doomed.
>People don't have the cognitive mechanisms to deal with that number
>and variety of mechanisms. The result is that each person uses their
>own personal subset of the language, and a Tower of Babel results.
>Far from being "common", Common Lisp is doomed to be uncommon.
>
> -- Scott Turner
I have to disagree with this particular example, (perhaps because
some and every are part of my working set). Sure, you can write
equivalent code in terms of do, or recursion. But there are common
patterns of usage of do* and recursion, that are worth having around
so they don't need to be re-invented from primitives each time. This
makes writing and reading code much easier for me.
I'd much rather see and write
(some #'(lambda(op)(solved? (apply-op op state))) operators)
than the equivalent with do, recursion, (or mapc with a return-from).
Indeed, there are some common patterns have been left out, that
I define as macros and use extensively. For example,
applying a function to each element of a list and consing together
the non-nil values.
(delete nil (mapcar #'fn list))
and
(let ((v))
(mapcan #'(lambda(x)(when (setq v (fn x))
(list v)))
list))
are less clear to me than
(all-images #'fn list)
Furthermore, all-images can be optimized once for this particular
purpose.
Mike
In article <·····················@aero.org> ···@aero.org (Scott "TCB" Turner) writes:
>EVERY, SOME, etc., are exactly the kind of "kitchen sink" functions
>that I object to in Common Lisp. They provide no additional
>functionality to the language, are semantically confusing, and make
>reading code difficult.
They're in there because for years Lisp wizards were being asked "why can't
I apply #'OR or #'AND?", so it became obvious that Lisp programmers want a
simple way of performing a logical operation on a list.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Vincent Delacour
Subject: Re: Common Lisp, SOME, EVERY...
Date:
Message-ID: <1954@seti.inria.fr>
In article <·····················@aero.org> ···@aero.org (Scott "TCB" Turner) writes:
>····@ccvax.ucd.ie writes:
> [...]
>A language that has a 1000 built-in functions (constructs) is doomed.
>People don't have the cognitive mechanisms to deal with that number
>and variety of mechanisms. The result is that each person uses their
> [...]
> -- Scott Turner
This, surely, is false. Many languages have more than 1000 words, and it is
no problem at all. Do you by any chance consider programming in any language
without the libraries ? In C or Ada there are much of those, and it is no
harm if you don't use both of them. Documentation helps you find the one
you want. It is a good thing to specify what a library does, because it
helps portability. I have an example, just everyday life : /bin/pr
does not behave the same on Suns and Vaxes (Ultrix) : this is a pain when
you use simple shell scripts on both machines. I do like format working
the same way in both Common Lisps.
[vd]
From: Jeff Dalton
Subject: Re: Common Lisp, SOME, EVERY...
Date:
Message-ID: <4238@skye.ed.ac.uk>
In article <·····················@aero.org> ···@aero.org (Scott "TCB" Turner) writes:
>EVERY, SOME, etc., are exactly the kind of "kitchen sink" functions
>that I object to in Common Lisp. They provide no additional
>functionality to the language, are semantically confusing, and make
>reading code difficult.
I do not regard them as "kitchen sink" functions at all. They are
not confusing, they make code easier to read, and (for those who
reserve their fury for _Common_ Lisp) they predate Common Lisp.
I used them in Franz Lisp, for example. But if you prefer to
write such operations out in-line each time, go ahead.
I think it is good practice to take useful operations and embody
them in functions. Just imagine how much worse programs would be
if people didn't do this.
>A language that has a 1000 built-in functions (constructs) is doomed.
>People don't have the cognitive mechanisms to deal with that number
>and variety of mechanisms.
Well, I guess they'll never be able to write large programs, use GNU
Emacs or the X Window System, etc. Yes, Emacs and X are standard
examples of "too big", and I'd rather Common Lisp were smaller (in
some ways). But these things are by no means doomed.
> The result is that each person uses their
>own personal subset of the language, and a Tower of Babel results.
>Far from being "common", Common Lisp is doomed to be uncommon.
Well, of course people use their own personal subset of the language,
just as, in a smaller language, they write their own personal extensions.
So instead of one Tower of Babel (if you think that's what happens) we
may get hundreds.
Once upon a time I wrote:
>A language that has a 1000 built-in functions (constructs) is doomed.
>People don't have the cognitive mechanisms to deal with that number
>and variety of mechanisms.
A number of people have responded to this with comments of the sort
"C has immense numbers of functions in libraries, and people deal
with that..."
I don't think comparing Common Lisp's plethora of built-ins with
library functions in other languages is completely relevant. For the
most part, library functions are not general programming constructs.
They perform specific computing tasks such as i/o, database retrieval,
statistical manipulations and so on.
There's no cognitive difficulty with that because there is still a one
to small mapping from tasks to functions to accomplish those tasks.
If I need to concatenate two strings in C, I can remember strcat[n].
C also has a one to small mapping for general programming constructs.
For iteration, I can remember for/while.
In Common Lisp, the mapping tends to be one to many. Even ignoring
functions which do implicit iteration, there are roughly fifteen
iteration constructs in Common Lisp. There are seven version of map!
(And as Michael Pazzanni pointed out, one of the most useful map
constructs isn't even represented.) That's neither necessary or
desirable.
Part of the problem seems to be lack of restraint on the part of the
design committee. Opening the manual at random, I see "case" and
"ccase", the difference being that "ccase" has no "otherwise" clause
and signals an error on fall-through. Is it necessary or desirable to
have two different functions for this? Why not have "case" signal an
error if there is no "otherwise" and fall-through occurs? Looking at
the language, it appears that every design conflict was resolved by
adding both sides to the language. It looks like someone grepped all
the functions out of five different AI programmers' code.
Another part of the problem is lack of organization. While Steele's
book tries to force a framework on Common Lisp, many functions simply
fall through the cracks, or make poor fits. (This is aggravated by
the inclusion of numerous seldom-used functions that don't truly
deserve to be an integral part of the language. Does Common Lisp
really need "prog2"? C'mon.) As several people have suggested, this
could be improved by organizing Common Lisp into general programming
constructs and specific libraries.
-- Scott Turner
In article <······················@aero.org>, Scott "TCB" Turner writes:
> A number of people have responded to this with comments of the sort
> "C has immense numbers of functions in libraries, and people deal
> with that..."
Not all of them do!
> I don't think comparing Common Lisp's plethora of built-ins with
> library functions in other languages is completely relevant. For the
Nor completely irrelevant.
> most part, library functions are not general programming constructs.
> They perform specific computing tasks such as i/o, database retrieval,
> statistical manipulations and so on.
Dont common Lisp functions perform specific computing tasks?
> There's no cognitive difficulty with that because there is still a one
> to small mapping from tasks to functions to accomplish those tasks.
> ...
> In Common Lisp, the mapping tends to be one to many.
Hmm. I'm not too sure about your mappings, there.
Perhaps this C isn't the ultimate standard, but in the C I've got to
play with, you get two partially overlapping sets of IO functions: one
using *FILE and the other using `handles'. It seems that every time I
wanted to write a program involving IO, 1/4 the functions I needed were
ONLY available using handles, another 1/4 ONLY available using *FILE.
What fun!
> ...
> Part of the problem seems to be lack of restraint on the part of the
> design committee.
Yeah, my thoughts exactly!
[Not to say there isn't a bit too much redundancy in CL, but still...]