Hi!
<newbie>
In Paul Graham's ACL section 10.1:
<quote>
If you call eval within a let, for example, the expresions passed to eval
cannot refer to variables established by the let.
</quote>
but in CLISP :
[14]> (setf a 30)
30
[15]> (let ((a 1)) (eval (+ 1 a)))
2
?!
</newbie>
TIA
--
,-------------------------- (~._.~) ----,
/ Shimon Cohen ( Y ) /
/ ·······@netvision.net.il ()~*~() /
'----------------------------- (_)-(_) -'
In article <··············@localhost.localdomain>, Shimon Cohen wrote:
>If you call eval within a let, for example, the expresions passed to eval
>cannot refer to variables established by the let.
></quote>
>but in CLISP :
>
>[14]> (setf a 30)
>30
>[15]> (let ((a 1)) (eval (+ 1 a)))
Here, eval is actually passed the value 2, not the form (+ 1 a),
because you did not quote it.
Try this instead:
(let ((a 1)) (eval '(1+ a)))
you will get the error you are looking for.
Then try this change:
(let ((a 1)) (eval `(1+ ,a)))
That's the trick you want if you want variables evaluated; use the
backquote, and then force evaluation within the quote using the comma.
This way, eval will actually get the form (1+ 1). Try it
without the eval and see:
(let ((a 1)) `(1+ ,a))
Hope this helps!
Shimon Cohen <·······@localhost.localdomain> wrote in
···················@localhost.localdomain:
> In Paul Graham's ACL section 10.1:
> <quote>
> If you call eval within a let, for example, the expresions passed to eval
> cannot refer to variables established by the let.
> </quote>
<newbie>
What happens in this case if you use let* instead of let?
Is 'Paul Graham's ACL' an online reference or a book?
Sounds like something I could use :-)
</newbie>
>>>>> "DM" == Donna <···········@mail.com> writes:
[on eval insida a let]
DM> <newbie> What happens in this case if you use let* instead of
DM> let?
No difference. Eval works in the "null lexical environment" meaning
no lexical bindings are available. Let, let* both establish lexical
bindings.
For the <newbie>, I consulted the Hyperspec for this:
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_eval.html#eval
If you are really interested you can click around in the Hyperspec and
get familiar with the terminology. (but maybe it is better if you
read a book first).
DM> Is 'Paul Graham's ACL' an online reference or a book? Sounds
DM> like something I could use :-) </newbie>
It is a book. ANSI Common Lisp is the full name. Amazon and previous
threads here should help you decide if you want it.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "DM" == Donna <···········@mail.com> writes:
> DM> Is 'Paul Graham's ACL' an online reference or a book? Sounds
> DM> like something I could use :-) </newbie>
>
> It is a book. ANSI Common Lisp is the full name. Amazon and previous
> threads here should help you decide if you want it.
ANSI Common Lisp is a good book, but it's far from the only good book
for people new to CL. In retrospect, it was a really good book for me
at the time that I read it, exactly because of its somewhat-Scheme-y
world view, which helped transition me into Common Lisp. For a lot of
people coming from languages like SmallTalk, or even C++, a book that
focuses on the Object-Oriented areas of CL would probably be much
better.
I bring this up, because I think maybe the reason a lot of people look
for Graham's books with such ferocity might be that they think they
together comprise the "Camel Book"[*] for Common Lisp. But CL is an
intentionally multi-paradigm language, which automatically makes it
impossible to have an equivalent to the Camel Book. The nearest thing
we have is the HyperSpec (of course, the nearest thing Perl has to a
spec is the Camel Book...).
[*] For those fortunate enough to not know what I'm talking about, the
"Camel Book" is the book written by Larry Wall (the primary author)
about Perl, and has a picture of a camel on the front. It's at once
the closest thing Perl has to a specification; a reference; and an
introduction to the language for experienced programmers from other
languages. It's also called the "Perl Bible", and is generally
considered the one book every Perl programmer should have on his/her
bookshelf. It's also massively over-rated, IMNSHO.