I am a beginner of LISP. And I encountered some problems...
If I enter the expressions at the command line
> (defun func (f2) (eval 'f2))
> (setq f2 nil)
> (setq var 'pi)
then I try to evaluate something:
> (func 'var)
NIL
> (func var)
NIL
Why? both the results are NIL! I think they should reply somghing like PI or
3.14159....
I use the Common Lisp interpreter.
Thanks!
* "Joe" <······@kimo.com.tw>
| I am a beginner of LISP. And I encountered some problems...
|
| If I enter the expressions at the command line
| > (defun func (f2) (eval 'f2))
| > (setq f2 nil)
| > (setq var 'pi)
|
| then I try to evaluate something:
| > (func 'var)
| NIL
| > (func var)
| NIL
|
| Why? both the results are NIL! I think they should reply somghing like PI or
| 3.14159....
EVAL evaluates the form in the current dynamic environment and the
null lexical environment.
--
Vebjorn Ljosa
"Joe" <······@kimo.com.tw> writes:
> If I enter the expressions at the command line
> > (defun func (f2) (eval 'f2))
>> (setq f2 nil)
>> (setq var 'pi)
>
> then I try to evaluate something:
> > (func 'var)
> NIL
> > (func var)
> NIL
>
> Why? both the results are NIL! I think they should reply somghing like PI or
> 3.14159....
The problem is that in Lisp every expression is an object, and can be
evaluated, giving another object. For most types of objects, such as
numbers, it does not make a difference: they are evaluated to
themselves. Thus, an _expression_ 1 is evaluated to 1. Two exceptions
are symbols, denoting variables, and lists, denoting function
applications. To calculate a value of a list (f e1 ... en) considered
as an _expression_ the ``function'' denoted by symbol f is ``applied''
in some sense to ``values'' of e1 ... en. There are three cases:
1. F denotes ordinary function, such as defined with DEFUN. In this
case e1 ... en are considered as _expressions_ and F is applied to
evaluated values of _expressions_ e1 ... en.
2. F denotes a `special form'. Then the corresponding function is
applied directly to _objects_ e1 ... en.
[3. F denotes a `macro'.]
'F2 is an abbreviation for (QUOTE F2). QUOTE denotes a `special form',
which returns its argument as it is. That is, the list (QUOTE Obj),
considered as an expression, is evaluated to the object Obj:
(QUOTE 1) => 1,
(QUOTE (+ 1 2)) => (+ 1 2).
>> (setq var 'pi)
The object associated with the symbol VAR will be the value of the
expression (QOUTE PI), that is the symbol PI (in other words VAR is
`binded' to PI).
> > (defun func (f2) (eval 'f2))
It means that ordinary function, associated with the symbol FUNC, when
applied to an object Obj, returns the value of the expression (EVAL
(QUOTE F2)), when F2 is binded to Obj. This value is obtained by
applying the ordinary function EVAL to "the value of the _expression_
(QUOTE F2), when F2 is binded to Obj, i.e. symbol F2". EVAL, applied
to the symbol F2, returns the value, associated with F2, which was given by:
>> (setq f2 nil)
Therefore, EVAL returns NIL.
If you redefine FUNC as follows:
(define func (f2) (eval f2)
then (func 'var) will be evaluated in this way
([Obj] means the value of the expression Obj, and {Sym} means
the function associated with symbol Sym):
[(func 'var)] =
{func} ([(quote var)]) =
{func} (var) =
``[(eval f2)] where [f2]=var'' =
{eval} (``[f2] where [f2]=var'') =
{eval} (var) =
[var] =
pi
[(func var)] =
{func} ([var]) =
{func} (pi) =
``[(eval f2)] where [f2]=pi'' =
{eval} (``[f2] where [f2]=pi'') =
{eval} (pi) =
[pi] =
3.14159...
Regards,
Alexey Dejneka
* Anette Stegmann <················@gmx.de>
| Here the literals "000" and "00" both evaluate to the same value, but the
| two literals are not identical, so they do not evaluate to themselve.
Common Lisp is not defined at the character level, like Scheme is.
///
--
The United Nations before and after the leadership of Kofi Annan are two
very different organizations. The "before" United Nations did not deserve
much credit and certainly not a Nobel peace prize. The "after" United
Nations equally certainly does. I applaud the Nobel committee's choice.
In article <················@naggum.net>, Erik Naggum wrote:
>* Anette Stegmann <················@gmx.de>
>| Here the literals "000" and "00" both evaluate to the same value, but the
>| two literals are not identical, so they do not evaluate to themselve.
>
> Common Lisp is not defined at the character level, like Scheme is.
In Scheme, 000 and 00 are external representations for the integer
zero. If you give 000 to a Scheme implementation's read-eval-print loop,
it will almost certainly print back some representation other than 000.
This, at least, is not different from Common Lisp, in which an object
can have many printed representations.
Could you elaborate? What aspects of Scheme are defined at the character
level, whose Lisp counterparts are not defined at that level?
···@ashi.footprints.net (Kaz Kylheku) writes:
>
> In article <················@naggum.net>, Erik Naggum wrote:
> >* Anette Stegmann <················@gmx.de>
> >| Here the literals "000" and "00" both evaluate to the same value, but the
> >| two literals are not identical, so they do not evaluate to themselve.
> >
> > Common Lisp is not defined at the character level, like Scheme is.
>
> In Scheme, 000 and 00 are external representations for the integer
> zero. If you give 000 to a Scheme implementation's read-eval-print loop,
> it will almost certainly print back some representation other than 000.
Some notation, yes. But not some different object. Same with CL.
> This, at least, is not different from Common Lisp, in which an object
> can have many printed representations.
Yes, I think the Scheme spec was recently patched (like in R5RS?)
to more or less paper over its earlier weakness in this area.
> Could you elaborate? What aspects of Scheme are defined at the character
> level, whose Lisp counterparts are not defined at that level?
It used to be that Scheme was defined in terms of text syntax (though it
was made pretty vague so people could handwave about the object stuff).
Things like gensyms were a problem under the old explanation because there
was no way to get a gensym into code, since the semantics was defined in
terms of how you wrote the text, and gensyms differed only in their object
pointer, not their printed rep. I think the latest scheme spec more or less
papers over this long-standing nuissance, though in a kind of odd way.
CL, by contrast, simply defines how input syntax translates to objects,
and then defines all syntax in terms of objects. I think Scheme syntax
is still defined in terms of read syntax, even though some reverse
relationship between structure and syntax is retroactively added.
I'd have to dredge out my scheme spec and look carefully to be more precise
and don't have time, but I hope this is enough to get you going if you care
to research more.
* Kaz Kylheku
| What aspects of Scheme are defined at the character level, whose Lisp
| counterparts are not defined at that level?
Like its Algol heritage, Scheme has been (Kent indicates that they may
have fixed this) defined such that it can be processed with a regular
lexer that does not operate with lists of Scheme objects.
It is quite interesting to watch how languages gain complexity when their
syntaxes are defined at the character level that reaches far into the
higher-level constructs and how they gain it when their syntaxes are
defined as the parsed representation of the lowest-level objects and the
higher-level constructs of the language is instead defined in terms of
those objects.
///
--
The United Nations before and after the leadership of Kofi Annan are two
very different organizations. The "before" United Nations did not deserve
much credit and certainly not a Nobel peace prize. The "after" United
Nations equally certainly does. I applaud the Nobel committee's choice.
In article <················@naggum.net>, Erik Naggum wrote:
>* Kaz Kylheku
>| What aspects of Scheme are defined at the character level, whose Lisp
>| counterparts are not defined at that level?
>
> Like its Algol heritage, Scheme has been (Kent indicates that they may
> have fixed this) defined such that it can be processed with a regular
> lexer that does not operate with lists of Scheme objects.
I last read it through R5RS a few days ago. The only thing that
struck out at me as appealing to the text representation is this:
4.2.6 Quasiquotation
...
If a comma appears followed immediately by an at-sign (@), then
the following expression must evaluate to a list; the opening
and closing parentheses of the list are then "stripped away"
and the elements of the list are inserted in place of the comma
at-sign expression sequence.
Had a good belly laugh over that! It's a good explanation for newbies,
but not a good specification. I'll re-read the document with more
meticulous care to see if I can spot any other similar things.
Anette Stegmann <················@gmx.de> writes:
> Here the literals "000" and "00" both evaluate to the same
> value, but the two literals are not identical, so they do not
> evaluate to themselve.
I think you are mixing up reading and evaluation. When Lisp
reads 000 or 00, it gets an integer 0. Lisp then evaluates the 0
and gets the result 0; the 0 evaluated to itself.
If you put quotes in front of the 000 and 00, then the numbers
would not be evaluated, but they would still turn to 0 and 0.
Anette Stegmann <················@gmx.de> writes:
> > 000
> 0
> > 00
> 0
>
> Here the literals "000" and "00" both evaluate to the same
> value, but the two literals are not identical, so they do not
> evaluate to themselve.
``Literals'' in your sense are not objects, ``000'' is not a _number_,
but a readable external _representation_ of the number ``0''; ``000''
is not evaluated, but ``0'' is. This dialog can be read as follows:
- read a string ``"000"'';
- convert it to number ``0'';
- evaluate the expression ``0''; the result is the same number ``0'';
- read a string ``"00"'';
- convert it to number ``0'';
- evaluate the expression ``0''; the result is the same number ``0''.
Both expressions are evaluated to themselves.
Regards,
Alexey Dejneka
P.S. In CLHS the term `literal' corresponds to objects, not to their
representations.
Sorry, in the Read-Eval-Print cycle I've missed the Print stage.
Alexey Dejneka <········@comail.ru> writes:
> > > 000
>> 0
>> > 00
>> 0
> This dialog can be read as follows:
>
> - read a string ``"000"'';
> - convert it to number ``0'';
> - evaluate the expression ``0''; the result is the same number ``0'';
- print the resulting number ``0'', i.e. show its external representation;
it looks like ``0'';
> - read a string ``"00"'';
> - convert it to number ``0'';
> - evaluate the expression ``0''; the result is the same number ``0'';
- print the resulting number ``0'', i.e. show its external representation;
it looks like ``0''.
Regards,
Alexey Dejneka
"Joe" <······@kimo.com.tw> writes:
> > (defun func (f2) (eval 'f2))
This function makes a lexical binding for the variable F2.
EVAL does not see lexical bindings.
If you wanted a dynamic binding instead, you could do this:
(defun func (f2)
(declare (special f2))
(eval 'f2))
> I use the Common Lisp interpreter.
Do you mean you use CLISP?
CL = Common Lisp = a standardized programming language, for which
there are many different interpreters and compilers.
CLISP = an interpreter and byte compiler that displays a
candelabrum when you start it.
"Joe" <······@kimo.com.tw> writes:
> I am a beginner of LISP. And I encountered some problems...
>
> If I enter the expressions at the command line
> > (defun func (f2) (eval 'f2))
To get what you wanted,
you don't want this quote ^
(defun func (f2) (eval f2))
would work better for you. Then
(func 'var) => pi
(func var) => 3.14159
However, func at this point is not doing more for you than eval.
(eval 'var) => pi
(eval var) => 3.14159
> > (setq f2 nil)
> > (setq var 'pi)
>
> then I try to evaluate something:
> > (func 'var)
> NIL
> > (func var)
> NIL
>
> Why? both the results are NIL! I think they should reply
> somghing like PI or 3.14159....
> I use the Common Lisp interpreter.
In article <············@news.seed.net.tw>, Joe wrote:
>I am a beginner of LISP. And I encountered some problems...
>
>If I enter the expressions at the command line
>> (defun func (f2) (eval 'f2))
The form 'f2 evaluates to the symbol f2. When you evaluate this value,
you will find that it has no lexical binding, because lexical bindings
are invisible to eval. The evaluation simply does not happen within the
calling lexical scope where f2 is bound to a value.
Anyway, what you are trying to do is completely useless, because in
order to have a form evaluated, you don't have to do anything at all.
Simply use it in a context where it is evaluated.
Given a variable var, if you wish to evaluate it, simply use the form
var
Your evaluator could be written as the following macro
(defmacro evaluate-this (x) x)
This will cause occurences of
(evaluate-this <form>)
to be replaced by
<form>
which is the useless thing you are looking for.
···@ashi.footprints.net (Kaz Kylheku) writes:
> In article <············@news.seed.net.tw>, Joe wrote:
> >I am a beginner of LISP. And I encountered some problems...
> >
> >If I enter the expressions at the command line
> >> (defun func (f2) (eval 'f2))
>
> The form 'f2 evaluates to the symbol f2. When you evaluate this value,
> you will find that it has no lexical binding, because lexical bindings
> are invisible to eval. The evaluation simply does not happen within the
> calling lexical scope where f2 is bound to a value.
You might want to read my very old but still somewhat relevant paper
http://world.std.com/~pitman/Papers/Special-Forms.html
It's mostly about macros, but it indirectly addresses the issue of why
EVAL fell out of favor in Lisp after a while. We still have it, and
it still has some special-purpose value, but it's not used in normal
day-to-day programming. In modern times, its use is reserved for
specialized situations. Statistically, most attempted uses of EVAL
are cues that a programmer confusion is lurking.
Btw, the subject line for this thread is incorrect. ;-)