Quote:
Original post by Way Walker
Quote:
Original post by Oberon_Command
Not quite. '() is the empty list, which evaluates to NIL, which is not a list. Since car evaluates its parameter before operating on it, meaning that (car '()) actually evaluates (car nil), you're actually applying car to something that is not a list.
Is it car that evaluates its parameter before operating on it, or does the implementation do that before sending it to car?
I'm not sure if it makes a difference, since there's nothing else that '() could be (it's NOT actually a list, semantically-speaking, we just treat it as one), but I believe it is the former. [edit:] That seems to be how quote and other special forms work. Functions "proper" might be different.
Quote:
What distinction are you making by calling the first one "just a list" as opposed to my "a list containing..."? Is it un-Lisp-like to say that a list contains certain elements?
You can say that a list contains certain elements, but you can't say that a list containing certain elements makes it in any way NOT a list. The distinction is that there IS no distinction - an unevaluated statement in Lisp is just a list. The code is represented in the same way data is, so the only difference between code and data is that one has meaningful results when it is treated as code.
Quote:
And the name of a function is a symbol? A string? Can it be manipulated? At what point does it replace the name with the function?
It is a symbol. It doesn't have any meaning until it is evaluated in some context. If that were not the case, you could not use quoted symbols that aren't actually bound to a variable, function, or macro. That is what the quote operator is actually for; preventing symbols from being evaluated. For instance:
; this statement...(let ((x 5) (y 2)) (cons (+ x y) (list 'x 'y 'z))) ; note that there is no such variable "z", yet we can still use it as a symbol(7 X Y Z) ; ... produces this list; likewise, this one...(list 'cons 'X 'Y)(CONS X Y) ; produces this; and this...(set 'x 1)(set 'y 2)(eval (list 'CONS 'x 'y))(1 . 2) ; produces this, at least in the Steel Bank Common Lisp implementation
Quote:
And does any of this affect my point? If it does, could you spell out the difference it makes to what I was saying? It's been a while since I've worked with Scheme so I could very easily be missing the implications of what you're saying. The snippet you put at the end looks, to my eye, to be demonstrating what I was saying.
I'm not actually disagreeing with your main point. I was just trying to enhance and clarify it by quibbling over details before somebody else who didn't agree with you did.
Quote:
(And there should only be one open parenthesis right after "let", right?)
No, there should be two. The first parameter to let is a list of variable associations, which are themselves lists. That confused me at first, too. [grin]
Quote:
Having first-class functions doesn't mean you don't see any difference between data and code.
The code/data relationship in Lisp isn't because of the fact that it has first-class functions. That's merely a consequence of the way it treats code in general. In Lisp, code
is data. Not all data is code, but all code in Lisp is data and is represented in exactly the same way. The only distinction arises when that data is evaluated by the runtime environment and either fails or produces meaningful results.
edit: Fixed parentheses [grin]
[Edited by - Oberon_Command on December 11, 2009 5:51:44 PM]