Hi all,
I'm now going through PAIP (chapter 6, match-if function) and there is
something the author uses but my CLISP v2.28 just doesn't grok. Simply
put, it boils down to:
[132]> (setq op '+ x 7 y 25)
25
[133]> (eval '(op x y))
*** - EVAL: the function OP is undefined
Why does EVAL evaluate x and y but doesn't evaluate op ?
Is this a problem with clisp or with the code from PAIP ?
Thanks in advance
Eli
"Eli Bendersky" <······@gmail.com> wrote:
> [132]> (setq op '+ x 7 y 25)
> 25
> [133]> (eval '(op x y))
>
> *** - EVAL: the function OP is undefined
>
> Why does EVAL evaluate x and y but doesn't evaluate op ?
EVAL evaluates the expression (op x y). Evaluating this Lisp expression
means to evaluate all arguments and then calling the function "op". "op"
is a variable, but not a function. If you want to use eval, you can do
something like this:
(eval `(,op x y))
or something like this:
(eval (list op x y))
But in general it is not a good idea to use EVAL at all, better funcall
or macros.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
+ "Eli Bendersky" <······@gmail.com>:
| I'm now going through PAIP (chapter 6, match-if function) and there is
| something the author uses but my CLISP v2.28 just doesn't grok. Simply
| put, it boils down to:
|
| [132]> (setq op '+ x 7 y 25)
| 25
| [133]> (eval '(op x y))
|
| *** - EVAL: the function OP is undefined
|
| Why does EVAL evaluate x and y but doesn't evaluate op ?
| Is this a problem with clisp or with the code from PAIP ?
I haven't read PAIP, but that code isn't proper Common Lisp.
Does the book use an older (pre-CL) Lisp dialect?
If so, and if you wish to use CL to work the examples, perhaps your
time is better spent learning CL a bit better before you return to the
book.
The big problem here is that CL has separate name spaces for functions
and values. If the value binding of a symbol contains a function, you
call that function with funcall, thus: (funcall op x y)
Another problem with your code is that you're supposed to declare the
variables op, x, y special before using setq on them. Or use defvar
or defparameter, which implicitly declare the variable special.
And thirdly, you should never need to use eval at all. Eval is mainly
for system building, not for everyday use.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + "Eli Bendersky" <······@gmail.com>:
>
> | I'm now going through PAIP (chapter 6, match-if function) and there is
> | something the author uses but my CLISP v2.28 just doesn't grok. Simply
> | put, it boils down to:
> |
> | [132]> (setq op '+ x 7 y 25)
> | 25
> | [133]> (eval '(op x y))
> |
> | *** - EVAL: the function OP is undefined
> |
> | Why does EVAL evaluate x and y but doesn't evaluate op ?
> | Is this a problem with clisp or with the code from PAIP ?
>
> I haven't read PAIP, but that code isn't proper Common Lisp.
> Does the book use an older (pre-CL) Lisp dialect?
> If so, and if you wish to use CL to work the examples, perhaps your
> time is better spent learning CL a bit better before you return to the
> book.
PAIP uses slightly-pre-ANSI Common Lisp; it was published in 1992.
That said, it's only slightly pre-ANSI: it's well aware of post-CLtL
developments, and I for one recommend it as a text for learning even
today's Common Lisp, as it comes with useful examples of non-trivial
programs -- it teaches concepts as well as CL.
That said, it would appear that the MATCH-IF defined on page 186 of my
copy does contain a bug; it binds variables using PROGV, but fails to
call potentially-bound operators correctly. The code distributed by
Norvig from his website has the bug worked around in the examples, by
using (funcall ?op ?x ?y) rather than (?op ?x ?y) as the code executed
by the ?if matched; as Harald has said, funcall is the operator for
calling a variable's value as a function.
> Another problem with your code is that you're supposed to declare the
> variables op, x, y special before using setq on them. Or use defvar
> or defparameter, which implicitly declare the variable special.
Just to be clear, this is a problem in Eli's reduced case, but not a
problem in Norvig's original (book) or corrected (downloadable) code.
Christophe
Christophe Rhodes wrote:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
> > + "Eli Bendersky" <······@gmail.com>:
> >
> > | I'm now going through PAIP (chapter 6, match-if function) and
there is
> > | something the author uses but my CLISP v2.28 just doesn't grok.
Simply
> > | put, it boils down to:
> > |
> > | [132]> (setq op '+ x 7 y 25)
> > | 25
> > | [133]> (eval '(op x y))
> > |
> > | *** - EVAL: the function OP is undefined
> > |
> > | Why does EVAL evaluate x and y but doesn't evaluate op ?
> > | Is this a problem with clisp or with the code from PAIP ?
> >
> > I haven't read PAIP, but that code isn't proper Common Lisp.
> > Does the book use an older (pre-CL) Lisp dialect?
> > If so, and if you wish to use CL to work the examples, perhaps your
> > time is better spent learning CL a bit better before you return to
the
> > book.
>
> PAIP uses slightly-pre-ANSI Common Lisp; it was published in 1992.
> That said, it's only slightly pre-ANSI: it's well aware of post-CLtL
> developments, and I for one recommend it as a text for learning even
> today's Common Lisp, as it comes with useful examples of non-trivial
> programs -- it teaches concepts as well as CL.
>
> That said, it would appear that the MATCH-IF defined on page 186 of
my
> copy does contain a bug; it binds variables using PROGV, but fails to
> call potentially-bound operators correctly. The code distributed by
> Norvig from his website has the bug worked around in the examples, by
> using (funcall ?op ?x ?y) rather than (?op ?x ?y) as the code
executed
> by the ?if matched; as Harald has said, funcall is the operator for
> calling a variable's value as a function.
>
I have a newer printing of PAIP which already has the bug fix from 1992
in. However, it still doesn't work. The PAIP code is now:
(defun match-if (pattern input bindings)
"Test an arbitrary expression involving variables.
The pattern looks like ((?if code) . rest)."
;; *** fix, rjf 10/1/92 (used to eval binding values)
(and (progv (mapcar #'car bindings)
(mapcar #'cdr bindings)
(eval (second (first pattern))))
(pat-match (rest pattern) input bindings)))
Since (second (first pattern)) gives '(?op ?x ?y) on the sample
code (right there on page 186), my CLISP signals the undefined
function problem, and rightly so, by what I gathered from your
kind explanation.
What fixes it is to change:
(eval (second (first pattern)))
To:
(eval (cons 'list (second (first pattern))))
Now CLISP doesn't complain, but match-if gives wrong results.
It looks like this code section of PAIP has some issues, so
I'll look better into it.
Eli
"Eli Bendersky" <······@gmail.com> writes:
>
> Hi all,
>
> I'm now going through PAIP (chapter 6, match-if function) and there is
> something the author uses but my CLISP v2.28 just doesn't grok. Simply
> put, it boils down to:
>
> [132]> (setq op '+ x 7 y 25)
> 25
> [133]> (eval '(op x y))
>
> *** - EVAL: the function OP is undefined
>
> Why does EVAL evaluate x and y but doesn't evaluate op ?
> Is this a problem with clisp or with the code from PAIP ?
Others have addressed the issue of PAIP.
To answer your direct question:
EVAL doesn't evaluate x and y. Since EVAL is a function, its argument
'(op x y) is evaluated to (OP X Y). Eval now tries to evaluate this
form. It does so by looking for a FUNCTION DEFINITION associated with
the symbol OP. It will also look for the VALUE of X and Y.
The evaluation rules for the function position and the argument position
are different in Common Lisp. So you would really need to use
(funcall op x y)
to get the effect that you want. This is actually better, in that it
avoids the use of EVAL. But if the form of what you are trying to
evaluate is more irregular, you might need to resort to something like
the following:
(eval `(,op ,x ,y))
where you explicitly do the substitution in the form passed to EVAL.
--
Thomas A. Russ, USC/Information Sciences Institute