Python syntax in Lisp and Scheme

[Peter Seibel]

"Terry Reedy" <tjreedy at udel.edu> writes:

> "Peter Seibel" <peter at javamonkey.com> wrote in message
> news:m34qyfibc8.fsf at javamonkey.com...

> > Note that it's the ability, at macro expansion time, to treat the
> > code as data that allows me to generate test failure messages that
> > contain the literal code of the test case *and* the value that it
> > evaluated to. I could certainly write a HOF version of CHECK that
> > accepts a list of test-case-functions:
> ...
> > But since each test case would be an opaque function object by the
> > time CHECK sees it, there'd be no good option for nice reporting
> > from the test framework.
> 
> But can't you explicitly quote the test cases for input to the HOF and
> eval them within the HOF, so you again have both the literal code and
> value generated?  Not as pretty, admittedly, and perhaps less
> efficient, but workable?

Well, if you eval the test cases, they are evaled in what's known as
the "null" lexical environment. So if you do something like:

  (let ((x 10))
    (check '(= (foo x) (* 2 x))))

where check is a function that evals its argument, rather than a
macro, then the evaluation will not be able to "see" the local binding
of the variable x so is unlikely to do what you think.

Python's eval--as I understand it--handles this differently. Common
Lisp's EVAL may be the way it is partially because it is not needed
for things like this given the existence of macros. There's are also
some semantic difficulties of what lexical environment the EVAL should
occur in. Given that the quoted expression above is just a piece of
data there's no particular way to attach the lexical environment to it
so that a subsequent EVAL can use it.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp