As stated in hyperspec, eval evaluates its form in the dynamic
environment and null lexical environment -- bummer.
This is what I was hoping to use eval for:
I have an a-list that stores pieces of code. I am using these
snippets to build code via macros. Here is part of the alist sigma^n
is in a lexical environment:
(let ((sigma^n
'((fromm ((i (q-slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
(i-1 (q-slope q^n_i q^n_i-2 (* 2 +DELTA-x+)))))
(beam-warming ((i (q-slope q^n_i q^n_i-1 +DELTA-x+))
(i-1 (q-slope q^n_i-1 q^n_i-2 +DELTA-x+))))
(lax-wendroff ((i (q-slope q^n_i+1 q^n_i +DELTA-x+))
(i-1 (q-slope q^n_i q^n_i-1 +DELTA-x+))))
..... )
The desired code are the (q-slope ...) forms.
There are two helper functions (index-code and scheme-code) to extract
the code based on whether I want fromm/beam-warming/lax-wendroff and i/
i-1 snippets. The macros that build the code call these functions to
insert the relevant code.
So far so good, and things work. But, I would like to test the
snippets themselves. I was hoping to do the following:
(let ((q^n_i+1 1.0)
(q^n_i-1 0.0)
(+delta-x+ 1.0))
(index-code 'i (scheme-code 'fromm)))
Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I
was hoping to assign the values of q^n_i+1, q^n_i-1 via the let
statement (all this being part of a unit-test).
For those that have followed this exposition, what is the idiomatic
way of doing this? The only other way I got it is:
(progn
(setq q^n_i+1 1.0
q^n_i-1 0.0
+delta-x+ 1.0)
(eval (index-code 'i (scheme-code 'fromm))))
which includes setq & eval. Now, minds greater than mine ofter object
to use of either of these, so I can only guess the reactions the
combination of two will cause :-)
So, again, is there a `cleaner' way than the setq/eval combo.
Thank you,
Mirko
On May 6, 10:50 pm, Mirko <·············@gmail.com> wrote:
> As stated in hyperspec, eval evaluates its form in the dynamic
> environment and null lexical environment -- bummer.
>
> This is what I was hoping to use eval for:
>
> I have an a-list that stores pieces of code. I am using these
> snippets to build code via macros. Here is part of the alist sigma^n
> is in a lexical environment:
>
> (let ((sigma^n
> '((fromm ((i (q-slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
> (i-1 (q-slope q^n_i q^n_i-2 (* 2 +DELTA-x+)))))
> (beam-warming ((i (q-slope q^n_i q^n_i-1 +DELTA-x+))
> (i-1 (q-slope q^n_i-1 q^n_i-2 +DELTA-x+))))
> (lax-wendroff ((i (q-slope q^n_i+1 q^n_i +DELTA-x+))
> (i-1 (q-slope q^n_i q^n_i-1 +DELTA-x+))))
> ..... )
>
> The desired code are the (q-slope ...) forms.
>
> There are two helper functions (index-code and scheme-code) to extract
> the code based on whether I want fromm/beam-warming/lax-wendroff and i/
> i-1 snippets. The macros that build the code call these functions to
> insert the relevant code.
>
> So far so good, and things work. But, I would like to test the
> snippets themselves. I was hoping to do the following:
> (let ((q^n_i+1 1.0)
> (q^n_i-1 0.0)
> (+delta-x+ 1.0))
> (index-code 'i (scheme-code 'fromm)))
>
> Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I
> was hoping to assign the values of q^n_i+1, q^n_i-1 via the let
> statement (all this being part of a unit-test).
>
> For those that have followed this exposition, what is the idiomatic
> way of doing this? The only other way I got it is:
> (progn
> (setq q^n_i+1 1.0
> q^n_i-1 0.0
> +delta-x+ 1.0)
> (eval (index-code 'i (scheme-code 'fromm))))
>
> which includes setq & eval. Now, minds greater than mine ofter object
> to use of either of these, so I can only guess the reactions the
> combination of two will cause :-)
>
> So, again, is there a `cleaner' way than the setq/eval combo.
>
> Thank you,
>
> Mirko
to do it the way that you want to do it, you need backquote.. (or at
least it is easier that way).
(eval `(let ((q^n_i+1 1.0)
(q^n_i-1 0.0)
(+delta-x+ 1.0))
,(index-code 'i (scheme-code 'fromm))))
So this acts kind of like a macro-expansion, where you get the 'let'
form followed by whatever code was looked up by index-code and scheme-
code. Although eval is in a null lexical environment, it evaluates
whatever list you feed it... :^)
On May 7, 12:19 am, ··················@gmail.com wrote:
> On May 6, 10:50 pm, Mirko <·············@gmail.com> wrote:
>
>
>
> > As stated in hyperspec, eval evaluates its form in the dynamic
> > environment and null lexical environment -- bummer.
>
> > This is what I was hoping to use eval for:
>
> > I have an a-list that stores pieces of code. I am using these
> > snippets to build code via macros. Here is part of the alist sigma^n
> > is in a lexical environment:
>
> > (let ((sigma^n
> > '((fromm ((i (q-slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
> > (i-1 (q-slope q^n_i q^n_i-2 (* 2 +DELTA-x+)))))
> > (beam-warming ((i (q-slope q^n_i q^n_i-1 +DELTA-x+))
> > (i-1 (q-slope q^n_i-1 q^n_i-2 +DELTA-x+))))
> > (lax-wendroff ((i (q-slope q^n_i+1 q^n_i +DELTA-x+))
> > (i-1 (q-slope q^n_i q^n_i-1 +DELTA-x+))))
> > ..... )
>
> > The desired code are the (q-slope ...) forms.
>
> > There are two helper functions (index-code and scheme-code) to extract
> > the code based on whether I want fromm/beam-warming/lax-wendroff and i/
> > i-1 snippets. The macros that build the code call these functions to
> > insert the relevant code.
>
> > So far so good, and things work. But, I would like to test the
> > snippets themselves. I was hoping to do the following:
> > (let ((q^n_i+1 1.0)
> > (q^n_i-1 0.0)
> > (+delta-x+ 1.0))
> > (index-code 'i (scheme-code 'fromm)))
>
> > Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> > slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I
> > was hoping to assign the values of q^n_i+1, q^n_i-1 via the let
> > statement (all this being part of a unit-test).
>
> > For those that have followed this exposition, what is the idiomatic
> > way of doing this? The only other way I got it is:
> > (progn
> > (setq q^n_i+1 1.0
> > q^n_i-1 0.0
> > +delta-x+ 1.0)
> > (eval (index-code 'i (scheme-code 'fromm))))
>
> > which includes setq & eval. Now, minds greater than mine ofter object
> > to use of either of these, so I can only guess the reactions the
> > combination of two will cause :-)
>
> > So, again, is there a `cleaner' way than the setq/eval combo.
>
> > Thank you,
>
> > Mirko
>
> to do it the way that you want to do it, you need backquote.. (or at
> least it is easier that way).
> (eval `(let ((q^n_i+1 1.0)
> (q^n_i-1 0.0)
> (+delta-x+ 1.0))
> ,(index-code 'i (scheme-code 'fromm))))
>
> So this acts kind of like a macro-expansion, where you get the 'let'
> form followed by whatever code was looked up by index-code and scheme-
> code. Although eval is in a null lexical environment, it evaluates
> whatever list you feed it... :^)
Wicked :-)
On Wed, 06 May 2009 19:50:11 -0700, Mirko wrote:
> As stated in hyperspec, eval evaluates its form in the dynamic
> environment and null lexical environment -- bummer.
>
> This is what I was hoping to use eval for:
>
> I have an a-list that stores pieces of code. I am using these snippets
> to build code via macros. Here is part of the alist sigma^n is in a
> lexical environment:
>
> (let ((sigma^n
> '((fromm ((i (q-slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
> (i-1 (q-slope q^n_i q^n_i-2 (* 2 +DELTA-x+)))))
> (beam-warming ((i (q-slope q^n_i q^n_i-1 +DELTA-x+))
> (i-1 (q-slope q^n_i-1 q^n_i-2 +DELTA-x+))))
> (lax-wendroff ((i (q-slope q^n_i+1 q^n_i +DELTA-x+))
> (i-1 (q-slope q^n_i q^n_i-1 +DELTA-x+))))
> ..... )
>
> The desired code are the (q-slope ...) forms.
>
> There are two helper functions (index-code and scheme-code) to extract
> the code based on whether I want fromm/beam-warming/lax-wendroff and i/
> i-1 snippets. The macros that build the code call these functions to
> insert the relevant code.
>
> So far so good, and things work. But, I would like to test the snippets
> themselves. I was hoping to do the following: (let ((q^n_i+1 1.0)
> (q^n_i-1 0.0)
> (+delta-x+ 1.0))
> (index-code 'i (scheme-code 'fromm)))
>
> Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I was
> hoping to assign the values of q^n_i+1, q^n_i-1 via the let statement
> (all this being part of a unit-test).
>
> For those that have followed this exposition, what is the idiomatic way
> of doing this? The only other way I got it is: (progn
> (setq q^n_i+1 1.0
> q^n_i-1 0.0
> +delta-x+ 1.0)
> (eval (index-code 'i (scheme-code 'fromm))))
>
> which includes setq & eval. Now, minds greater than mine ofter object
> to use of either of these, so I can only guess the reactions the
> combination of two will cause :-)
>
> So, again, is there a `cleaner' way than the setq/eval combo.
Hi Mirko,
Maybe I am not getting something about your problem, but couldn't you
just use closures?
Eg (if I am getting it right)
(let ((sigma^n
(list (lambda (q^n_i+1 q^n_i-1)
( q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
...
Then you would extract and call the anonymous functions. If the
tricky part is the code generation, then you can still use macros for
that.
Tell me if I didn't understand your problem. Sometimes you do need
eval I guess, but I have managed to avoid it so far, and it was always
to my benefit.
Tamas
On May 6, 11:41 pm, Tamas K Papp <······@gmail.com> wrote:
> On Wed, 06 May 2009 19:50:11 -0700, Mirko wrote:
> > As stated in hyperspec, eval evaluates its form in the dynamic
> > environment and null lexical environment -- bummer.
>
> > This is what I was hoping to use eval for:
>
> > I have an a-list that stores pieces of code. I am using these snippets
> > to build code via macros. Here is part of the alist sigma^n is in a
> > lexical environment:
>
> > (let ((sigma^n
> > '((fromm ((i (q-slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
> > (i-1 (q-slope q^n_i q^n_i-2 (* 2 +DELTA-x+)))))
> > (beam-warming ((i (q-slope q^n_i q^n_i-1 +DELTA-x+))
> > (i-1 (q-slope q^n_i-1 q^n_i-2 +DELTA-x+))))
> > (lax-wendroff ((i (q-slope q^n_i+1 q^n_i +DELTA-x+))
> > (i-1 (q-slope q^n_i q^n_i-1 +DELTA-x+))))
> > ..... )
>
> > The desired code are the (q-slope ...) forms.
>
> > There are two helper functions (index-code and scheme-code) to extract
> > the code based on whether I want fromm/beam-warming/lax-wendroff and i/
> > i-1 snippets. The macros that build the code call these functions to
> > insert the relevant code.
>
> > So far so good, and things work. But, I would like to test the snippets
> > themselves. I was hoping to do the following: (let ((q^n_i+1 1.0)
> > (q^n_i-1 0.0)
> > (+delta-x+ 1.0))
> > (index-code 'i (scheme-code 'fromm)))
>
> > Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> > slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I was
> > hoping to assign the values of q^n_i+1, q^n_i-1 via the let statement
> > (all this being part of a unit-test).
>
> > For those that have followed this exposition, what is the idiomatic way
> > of doing this? The only other way I got it is: (progn
> > (setq q^n_i+1 1.0
> > q^n_i-1 0.0
> > +delta-x+ 1.0)
> > (eval (index-code 'i (scheme-code 'fromm))))
>
> > which includes setq & eval. Now, minds greater than mine ofter object
> > to use of either of these, so I can only guess the reactions the
> > combination of two will cause :-)
>
> > So, again, is there a `cleaner' way than the setq/eval combo.
>
> Hi Mirko,
>
> Maybe I am not getting something about your problem, but couldn't you
> just use closures?
>
> Eg (if I am getting it right)
>
> (let ((sigma^n
> (list (lambda (q^n_i+1 q^n_i-1)
> ( q^n_i+1 q^n_i-1 (* 2 +DELTA-x+)))
> ...
>
> Then you would extract and call the anonymous functions. If the
> tricky part is the code generation, then you can still use macros for
> that.
>
> Tell me if I didn't understand your problem. Sometimes you do need
> eval I guess, but I have managed to avoid it so far, and it was always
> to my benefit.
>
> Tamas
Well, I did not think of wrapping the code into a lambda. I will
remember that.
Maybe I am really pushing macros too much. So, I am going to show you
what I am up to.
I am writing a 1-d solver for hyperbolic partial differential
equations, and I want to implement a few of the linear and nonlinear
stepping schemes.
In general, the equation for stepping is the same for all schemes,
except for two terms. The code for these differing terms is stored in
that alist. So, here is the general routine for stepping, that will
return the code to be evaluated by a macro:
(defun general-step-code (&optional (scheme 'lax-wendroff))
"Returns code for a general step at index `i' using `scheme'"
`(setf q^n+1_i
(- q^n_i
(* u.delta-t/delta-x_i (- q^n_i q^n_i-1))
(* 0.5 u.delta-t/delta-x_i (- +DELTA-x+ (* +u+ +DELTA-t+))
(- ,(index-code 'i (scheme-code scheme))
,(index-code 'i-1 (scheme-code scheme)))))))
Above are the calls to index-code and scheme-code with which I extract
the correct code.
general-step-code is called by a macro that will generate the code to
step the solution across the problem domain for one step:
(defmacro bulk-evaluation (index scheme)
"Generate code to evaluate in bulk using `scheme'"
`(do ((,index +i-bulk-min+ (incf ,index)))
((= ,index +i-bulk-max+))
(with-_-indexing ((i i)
(i-1 (1- i)) (i+1 (1+ i))
(i-2 (- i 2)) (i+2 (+ i 2)))
,(general-step scheme))))
(the with-_-indexing macro will substitute all foo^n_i+1 by (aref
foo^n (1+ i)), for example - actually it will setup the translation
using symbol-macrolet)
Finally, I define my stepper function that will step the solution by
one step.
(defun lw-step (q^n+1 q^n)
(bulk-evaluation i lax-wendroff))
(The function will get more complicated to include boundary
conditions)
Admittedly, this could be a gross abuse of macros. But I am still
feeling my way to find the right way to do things. What I like about
the above is that it broke down the problem into several fairly
independent pieces.
Mirko
On Thu, 07 May 2009 09:32:42 -0700, Mirko wrote:
> Admittedly, this could be a gross abuse of macros. But I am still
Yes, I think so, but I guess that is OK. I have also abused macros
quite a bit when I was learning about them. The important thing is to
recognize that you are abusing macros and learn from it. Macros are
very forgiving, they won't remember later that you have abused them in
the past :-)
> feeling my way to find the right way to do things. What I like about
> the above is that it broke down the problem into several fairly
> independent pieces.
I think you can do the same with closures, but admittetly I didn't
check this.
Learning to write a partial diff. eq. solver is a great exercise.
Maybe you could do the following: recognize that most of these methods
just walk a grid, generating outputs from inputs using certain rules.
Encode the rules in stencil-like structures composed of relative grid
positions and closures, and write a generalized "solver" that walks
the whole grid using one of these stencils.
Then, when applied to a particular problem, the solver would receive
functions as inputs, and generate the appropriate closures, and call
the solver.
Just an idea, I didn't think about the fine details, corner cases, etc.
Tamas
On May 7, 12:49 pm, Tamas K Papp <······@gmail.com> wrote:
> On Thu, 07 May 2009 09:32:42 -0700, Mirko wrote:
> > Admittedly, this could be a gross abuse of macros. But I am still
>
> Yes, I think so, but I guess that is OK. I have also abused macros
> quite a bit when I was learning about them. The important thing is to
> recognize that you are abusing macros and learn from it. Macros are
> very forgiving, they won't remember later that you have abused them in
> the past :-)
>
> > feeling my way to find the right way to do things. What I like about
> > the above is that it broke down the problem into several fairly
> > independent pieces.
>
> I think you can do the same with closures, but admittetly I didn't
> check this.
You are probably right, since closures are low-level `objects'
>
> Learning to write a partial diff. eq. solver is a great exercise.
> Maybe you could do the following: recognize that most of these methods
> just walk a grid, generating outputs from inputs using certain rules.
>
> Encode the rules in stencil-like structures composed of relative grid
> positions and closures, and write a generalized "solver" that walks
> the whole grid using one of these stencils.
>
> Then, when applied to a particular problem, the solver would receive
> functions as inputs, and generate the appropriate closures, and call
> the solver.
>
> Just an idea, I didn't think about the fine details, corner cases, etc.
>
> Tamas
I will think about that, since, for one thing, closures are probably
easier to debug.
Thanks
On May 7, 5:50 am, Mirko <·············@gmail.com> wrote:
> Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I
> was hoping to assign the values of q^n_i+1, q^n_i-1 via the let
> statement (all this being part of a unit-test).
This is your problem -- I think a few of the other posters might not
have noticed it.
As far as I understand it, you want index-code and scheme-code to
extract some code from a list. Your problem is that you're having
those functions call eval on the code. THAT is the problem.
The functions themselves should just extract the code directly, and
return it unevaluated. In other words, assuming that you stick with
your alist of code plan, those two functions would probably be
something like:
(defun scheme-code (scheme)
(cdr (assoc scheme sigma^n)))
(defun index-code (index code)
(cdr (assoc index code)))
Keep in mind that code generated by macros is evaluated after the
macroexpansion -- thus, if scheme-code and index-code called (eval) on
their arguments, and were used in macros, you'd end up with some code
being doubly evaluated -- I'm not sure that's what you want.
On May 7, 7:26 am, Adlai <·········@gmail.com> wrote:
> On May 7, 5:50 am, Mirko <·············@gmail.com> wrote:
>
> > Here (index-code 'i (scheme-code 'fromm)) extracts the code snippet (q-
> > slope q^n_i+1 q^n_i-1 (* 2 +DELTA-x+))) and passes it on to eval. I
> > was hoping to assign the values of q^n_i+1, q^n_i-1 via the let
> > statement (all this being part of a unit-test).
>
> This is your problem -- I think a few of the other posters might not
> have noticed it.
>
> As far as I understand it, you want index-code and scheme-code to
> extract some code from a list. Your problem is that you're having
> those functions call eval on the code. THAT is the problem.
>
> The functions themselves should just extract the code directly, and
> return it unevaluated. In other words, assuming that you stick with
> your alist of code plan, those two functions would probably be
> something like:
>
> (defun scheme-code (scheme)
> (cdr (assoc scheme sigma^n)))
>
> (defun index-code (index code)
> (cdr (assoc index code)))
>
> Keep in mind that code generated by macros is evaluated after the
> macroexpansion -- thus, if scheme-code and index-code called (eval) on
> their arguments, and were used in macros, you'd end up with some code
> being doubly evaluated -- I'm not sure that's what you want.
Adlai,
I do not use eval anywhere in my production code. I only wanted to
use it to evaluate the code snippets for testing purposes. But, you
devined correctly the code that I use for accessing the snippets.
Thanks,
Mirko
From: Kaz Kylheku
Subject: Re: (let ... (eval ...)) does not work, so what does?
Date:
Message-ID: <20090517225439.893@gmail.com>
On 2009-05-07, Mirko <·············@gmail.com> wrote:
> For those that have followed this exposition, what is the idiomatic
> way of doing this? The only other way I got it is:
> (progn
> (setq q^n_i+1 1.0
> q^n_i-1 0.0
> +delta-x+ 1.0)
> (eval (index-code 'i (scheme-code 'fromm))))
(eval `(let ((q^n_i+1 1.0) ..) ,(index-code 'i (scheme-code 'fromm))))
I.e. stick the a lexical environment into the code being evaluated.
Note that (scheme-code 'fromm) could match the symbol to a function
rather than to source code. Your alist could associate symbols with lambdas.
The lambdas can take a standardized argument list:
(let ((alist `((fromm ,(lambda (q^n_1+1 ..) ... ))
(foo ,(lambda ...)))))
(funcall (second (assoc alist 'fromm)) 1.0 0.0 1.0))
Instead of an association list, you could just create a big CASE or ECASE
statement.
(defun compute-it (symbol q^n_i+1 q^n_i+1 delta-x)
(ecase symbol
(fromm (... code for fromm case))
(... other cases )))
I mean, it seems to boil down to choosing a function, and applying
some parameters to it.
Save the dynamic EVAL or COMPILE for when you actually have code
that writes code based on info that is only available at run time.
On May 7, 3:08 am, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-05-07, Mirko <·············@gmail.com> wrote:
>
> > For those that have followed this exposition, what is the idiomatic
> > way of doing this? The only other way I got it is:
> > (progn
> > (setq q^n_i+1 1.0
> > q^n_i-1 0.0
> > +delta-x+ 1.0)
> > (eval (index-code 'i (scheme-code 'fromm))))
>
> (eval `(let ((q^n_i+1 1.0) ..) ,(index-code 'i (scheme-code 'fromm))))
>
> I.e. stick the a lexical environment into the code being evaluated.
>
> Note that (scheme-code 'fromm) could match the symbol to a function
> rather than to source code. Your alist could associate symbols with lambdas.
> The lambdas can take a standardized argument list:
>
> (let ((alist `((fromm ,(lambda (q^n_1+1 ..) ... ))
> (foo ,(lambda ...)))))
> (funcall (second (assoc alist 'fromm)) 1.0 0.0 1.0))
>
> Instead of an association list, you could just create a big CASE or ECASE
> statement.
>
> (defun compute-it (symbol q^n_i+1 q^n_i+1 delta-x)
> (ecase symbol
> (fromm (... code for fromm case))
> (... other cases )))
>
> I mean, it seems to boil down to choosing a function, and applying
> some parameters to it.
>
> Save the dynamic EVAL or COMPILE for when you actually have code
> that writes code based on info that is only available at run time.
You are right, I could have gone the way of choosing the function
code. As I noted to Tamas, I am having too much fun with macros, and
maybe I have overdone it.
Thanks,
Mirko
From: Thomas A. Russ
Subject: Re: (let ... (eval ...)) does not work, so what does?
Date:
Message-ID: <ymi63gcohxv.fsf@blackcat.isi.edu>
Mirko <·············@gmail.com> writes:
> As stated in hyperspec, eval evaluates its form in the dynamic
> environment and null lexical environment -- bummer.
Perhaps you should look into PROGV to wrap around your EVAL?
--
Thomas A. Russ, USC/Information Sciences Institute