While working through various lisp introductions and generally playing with
it, I've hit a couple of things I don't get.
(1) Why does
(+ '(5 6)) give (5 6) rather than an error?
(2) Why is it that
(mapcar #'not (list nil 'nil)) gives (T T) as expected, but
(mapcar #'not '(nil 'nil)) gives (T NIL) ?
thanks in advance...
"smeckler" <······················@hotmail.com> writes:
> While working through various lisp introductions and generally
> playing with it, I've hit a couple of things I don't get.
>
> (1) Why does
> (+ '(5 6)) give (5 6) rather than an error?
The standard says that an implementation "might signal type-error if
some argument is not a number", i.e. it doesn't have to. I'd say that
it isn't good style not to signal an error but it doesn't look as if
it were a violation of the standard.
(I guess you're using CMUCL. All other implementations I've tried -
SBCL, LispWorks, AllegroCL, CLISP, ECL - in fact signal an error
here.)
> (2) Why is it that
> (mapcar #'not (list nil 'nil)) gives (T T) as expected, but
> (mapcar #'not '(nil 'nil)) gives (T NIL) ?
'(NIL 'NIL) is short for (QUOTE (NIL (QUOTE NIL))) which by definition
of the QUOTE special operator will result in (NIL (QUOTE NIL)),
i.e. the second element of the list is a non-empty list which is
"true".
(MAPCAR #'NOT (LIST NIL 'NIL)) will yield what you expect.
Edi.
> > (1) Why does
> > (+ '(5 6)) give (5 6) rather than an error?
>
> The standard says that an implementation "might signal type-error if
> some argument is not a number", i.e. it doesn't have to. I'd say that
> it isn't good style not to signal an error but it doesn't look as if
> it were a violation of the standard.
>
> (I guess you're using CMUCL. All other implementations I've tried -
> SBCL, LispWorks, AllegroCL, CLISP, ECL - in fact signal an error
> here.)
Actually it's Corman lisp. It seems to be specifically calling + with one
argument that's a list which gives this unexpected behaviour, any other
error *is* flagged.
Thanks for your help.
smeckler wrote:
> Actually it's Corman lisp. It seems to be specifically calling + with one
> argument that's a list which gives this unexpected behaviour, any other
> error is flagged.
I would imagine it's an optimization. Remember that (+ <x>) for a numeric
<x> evaluates to <x>. So it's not an error -- just an optimization that
removes the type check and, since +'s behavior is undefined for a
non-numeric argument, it would seem as if it's one of those "So don't do
that!" things.
faa
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<··················@news.uswest.net>...
> smeckler wrote:
>
> > Actually it's Corman lisp. It seems to be specifically calling + with one
> > argument that's a list which gives this unexpected behaviour, any other
> > error is flagged.
>
> I would imagine it's an optimization.
While it's true that it shouldn't cause a problem in legal common lisp
code, I regard it as a bug, because I intended it to signal an error.
And yes, it will only happen in the one-argument case. The '+ function
takes a variable number of arguments, and is implemented by a kernel
function which itself calls an internal function _Add for pairs of
arguments. In the one argument case, _Add never gets called, and types
never get checked. This appears to happen for '* as well.
Roger
"smeckler" <······················@hotmail.com> writes:
>
> While working through various lisp introductions and generally playing with
> it, I've hit a couple of things I don't get.
>
> (1) Why does
> (+ '(5 6)) give (5 6) rather than an error?
Beats me. In my lisps it gives an error.
> (2) Why is it that
> (mapcar #'not (list nil 'nil)) gives (T T) as expected, but
> (mapcar #'not '(nil 'nil)) gives (T NIL) ?
That is because of a number of things. The chief one among them being
that NIL evaluates to NIL, so it isn't necessary to quote it when
passing it to a function. So in the first case, you apply LIST to NIL
and 'NIL. They are both evaluated. The first evaluates to NIL because
NIL evalautes to itself. The second one evaluates to NIL because it is
quoted, and evaluating a quoted value gives you the value itself.
In the second case, you have a literal list '(NIL 'NIL) which is
evaluated to be the list (NIL 'NIL). Now it so happens that ' is a
reader macro and thus just a convenient abbreviation for the QUOTE
special form. So what you have is actually the list
(NIL (QUOTE NIL)) but written as (NIL 'NIL)
The first item in the list is NIL, but the second item is a LIST with
NIL as the second element and the symbol QUOTE as the first element.
This list is not equal to NIL, so NOT correctly returns NIL.
>
>
> thanks in advance...
>
>
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu