In article <············@dalembert.cs.widener.edu> ····@cs.widener.edu (Sven Heinicke) writes:
Is there anyway to get something like this to work:
> (setq equation '(mod a b))
(* mod a b)
> (let ((a 20)(b 7)) (eval equation))
6
and I can't use a setq on a and b.
Sorry if this is a dumb question.
Let's address the problems one at a time. I am assuming you are using
Common Lisp (if you are using Scheme some of my points do not apply).
By setq'ing EQUATION to '(mod a b), all you have done is to bind the
symbol EQUATION to a list containing three elements (the symbols MOD,
A and B).
Anytime EQUATION is now EVAL'ed, you get back that list of three
symbols. If you really wanted to evaluated the resultant list, you
would have to call eval again. However you have a problem in that
EVAL evaluates it arguments in a NULL lexical environment (ie as if
you typed it in at the top-level. This statements is NOT true for
Scheme; in Scheme EVAL uses the current lexical environment).
Therefore a and b would need to be SETQ'd themselves in order for this
to work (which you said you cannot do).
(setq equation '(mod a b))
(setq a 20
b 7)
(eval (eval equation))
This is bad style anyway even if you could do it. I don't know what
your constraints are but a LAMBDA is probably what you are looking
for.
(setf equation #'(lambda (peanut butter) (mod peanut butter)))
(let ((a 20) (b 7)) (funcall equation a b))
Now EQUATION is bound to an actual function object. I purposely named
its parameters something silly to show how it is removed from
depending on A and B. If you really need to depend an A and B you can
do it this way (though this is not as clean as the last example).
(setf equation #'(lambda () (mod a b)))
(let ((a 20) (b 7))
(declare (special a b))
(funcall equation))
The declare statement tells Lisp to bind A and B dynamically instead
of lexically.
David Kuznick
·····@ait.com
(setq equation '(mod a b))
(setq a 20
b 7)
(eval (eval equation))
Whoops! I messed up. No need to do two evals. Eval is a function so
it's arguments get EVALled before they are appiled. Must of been
those bananas I was smoking...
David Kuznick
·····@ait.com
In article <······················@ait.com>, ·····@ait.com (David Kuznick) writes:
> In article <············@dalembert.cs.widener.edu> ····@cs.widener.edu (Sven Heinicke) writes:
> Is there anyway to get something like this to work:
>
> > (setq equation '(mod a b))
> (* mod a b)
> > (let ((a 20)(b 7)) (eval equation))
> 6
>
> and I can't use a setq on a and b.
> Sorry if this is a dumb question.
>
> Let's address the problems one at a time. I am assuming you are using
> Common Lisp (if you are using Scheme some of my points do not apply).
>
> By setq'ing EQUATION to '(mod a b), all you have done is to bind the
> symbol EQUATION to a list containing three elements (the symbols MOD,
> A and B).
>
> Anytime EQUATION is now EVAL'ed, you get back that list of three
> symbols. If you really wanted to evaluated the resultant list, you
> would have to call eval again.
No, whatever problems he is having, this is *NOT* one of them.
EQUATION, since it appears unquoted in the code as an argument
to EVAL, is being evaluated by the evaluator (or compiled code)
before passing it to EVAL. So EVAL is receiving (MOD A B)
as its argument.
> However you have a problem in that
> EVAL evaluates it arguments in a NULL lexical environment (ie as if
> you typed it in at the top-level.
True.
> (setf equation #'(lambda (peanut butter) (mod peanut butter)))
> (let ((a 20) (b 7)) (funcall equation a b))
Yes.
> The declare statement tells Lisp to bind A and B dynamically instead
> of lexically.
But (as you said), usually you do not want to do things this way.
It is both less efficient and less modular, because the variables
A and B will be bound inside any code called inside the EVAL. If
the domain is symbolics mathematics, I *STRONGLY* urge you to avoid
special variables. Macsyma's internals are a good example of the
kind of mess you get into with using special variables in ways like
this. (In fairness to Macsyma, it pre-dates the modern ideas and
language facilities).