* "Joe" <cf9...@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.
"Joe" <cf9...@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
> 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.
> > > 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''.
* Anette Stegmann <anette_stegma...@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.
Anette Stegmann <anette_stegma...@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.
In article <9qbam7$9n...@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
k...@ashi.footprints.net (Kaz Kylheku) writes: > In article <9qbam7$9n...@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
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. ;-)
In article <3212051527684...@naggum.net>, Erik Naggum wrote: >* Anette Stegmann <anette_stegma...@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?
> In article <3212051527684...@naggum.net>, Erik Naggum wrote: > >* Anette Stegmann <anette_stegma...@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 <3212128554160...@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.
