LISP has the setf function to assign a value to a variable. Now I have been wondering about the function's name: The set part is obvious, but what does the f suffix stand for?
The actual meaning of F is often forgotten. According to some sources, f suffix could stand for:
Field (see for example this answer)
Form (as seen in various teaching materials and manuals)
However, according to Gabriel and Steele's The Evolution of Lisp, SETF comes from Peter Deutsch's A Lisp Machine with Very Compact Programs (published in 1973) and F stands for function.
In this paper, Peter Deutsch wrote:
The SET function is extended so that so that if the first argument is a list (fn argl ... argn) rather than a variable, the function fn is called in "store" mode with arguments argl ... argn and newvalue (the second argument of SET). SETQ is also extended in the obvious way, but is not particularly useful. A more useful function is (SETFQ (fn argl ... argn) newvalue) which quotes the function name and evaluates everything else. This allows RPLACA, for example, to be defined as (LAMBDA (X Y) (SETFQ (CAR X) Y)).
(emphasis mine)
Gabriel and Steele explain how this became SETF:
This name was abbreviated to SETF in Lisp-Machine Lisp.
Related
I'm new with common-lisp and my stuck with this easy problem.
I need to define a function that return true if the input is an atom
So, if in enter in the command line atom 'a returns T, but my code not
Variable x has to be quoted or the result will be false.
(defun check (x)
if(atom 'x)
T)
There already is a function that does that. It is called atom:
(atom 1)
=> T
(atom '(1))
=> NIL
This is thus a rather pointless exercise. If you absolutely must, you could wrap it in another function call:
(defun pointless-exercise (x)
(atom x))
(pointless-exercise 1)
=> T
(pointless-exercise '(1))
=> NIL
Note that you absolutely must not quote that x in your function:
(defun failed-exercise (x)
(atom 'x))
-> WARNING: parameter x is unused
(failed-exercise 1)
=> T
(failed-exercise '(1))
=> T ; oops
That is because 'x means that the symbol x stands for itself and is not evaluated as a variable name, and a symbol is always an atom.
[This is an extended comment which is too long for one.]
Based on your comments either you are confused or your function cannot be written in Common Lisp.
Here's why:
you are writing a function, and so your function will obey the standard evaluation rules of the language for function applications;
you require your function, check to return t in a form (check a) where a is not previously known.
These two conditions can not be met. They can't be met because the evaluation rules for the language forbid it. In a form like (check a) the rules are:
find out what sort of thing check refers to;
if it refers to a function, evaluate all its arguments in left-to-right order in the current environment;
retrieve the function binding of check from the current environment (this step can happen before, after, or during (2));
apply it to the results of (2).
See 3.1.2.1.2.3 of the Hyperspec.
In your case this process fails at (2): a has no binding and so evaluation of a signals an error.
Given that you are being asked to write a function you must have misunderstood the question.
Further, it's unlikely that you were being asked merely to write a wrapper around atom: rather the chances are the question wanted you either to reimplement atom (hint: what is its definition?), or to implement some variant of atom which considers a different set of objects to be 'atomic' than atom does. Which of those is true we can't tell from your question as it stands (v1).
While learning Lisp, I've seen that if there are two parameters to a function, where one is a single element or a subset (needle), and the other is a list (haystack), the element or subset always comes first.
Examples:
(member 3 '(3 1 4 1 5))
(assoc 'jane '((jane doe)
(john doe)))
(subsetp '(a e) '(a e i o u))
To me, it seems as if there was a rule in Lisp that functions should follow this guidance: Part first, entire thing second.
Is this finding actually based on a guideline in Lisp, or is it accidentally?
Functions like member and assoc are at least from 1960.
I would simply expect that it followed mathematical notation, for example in set theory:
e ∈ m
Since Lisp uses prefix notation, the predicate/function/operator comes first, the element second and the set is third:
(∈ e m)
John McCarthy had a Ph.D. in Mathematics.
Generally it is also more useful in Common Lisp to have set-like argument last:
(defun find-symbol (name package) ...)
The actual definition in Common Lisp is:
(defun find-symbol (name &optional (package *package*)) ...)
This allows us to use the current package as a useful default.
Lets see. The first McCarthy LISP from 1960 had the list sometimes as the first argument. See page 123 in this LISP manual. E.g.
;; 1960 maplist
(defun maplist (list function)
...)
Now this is perhaps because this function was one of the first higher order functions that were made. In fact it predated the first implementation as it was in the first Lisp paper. In the same manual on page 125 you'll find sassoc and it looks very much like assoc today:
(defun sassoc (needle haystack default-function)
...)
Both of these look the same in the next version 1.5 of the language. (See page 63 for maplist and 60 for sassoc)
From here to Common Lisp there are divergent paths that joins again. A lot of new ideas came about but there has to be a reason to break compatibility to actually do it. I can think of one reason and that is support for multiple lists. In Common Lisp maplist is:
(defun maplist (function &rest lists+)
...)
A quick search in the CLHS for common argument names in "wrong" order gave me fill, map-into, and sort. There might be more.
Peter Norvigs style guide say to follow conventions but not more detailed than that. When reading Scheme SRFIs they often mention defacto implementations around and what Common Lisp has as solution before suggesting something similar as a standard. I do the same when choosing how to implement things.
I'm trying to learn and understand the Lisp programming language to a deep level. The function + evaluates its arguments in applicative order:
(+ 1 (+ 1 2))
(+ 1 2) will be evaluated and then (+ 1 3) will be evaluated, but the if function works differently:
(if (> 1 2) (not-defined 1 2) 1)
As the form (not-defined 1 2) isn't evaluated, the program doesn't break.
How can the same syntax lead to different argument evaluation? How is the if function defined so that its arguments aren't evaluated?
if is a special operator, not an ordinary function.
This means that the normal rule that the rest elements in the compound form are evaluated before the function associated with the first element is invoked is not applicable (in that it is similar to macro forms).
The way this is implemented in a compiler and/or an interpreter is that one looks at the compound form and decides what to do with it based on its first element:
if it is a special operator, it does its special thing;
if it is a macro, its macro-function gets the whole form;
otherwise it is treated as a function - even if no function is defined.
Note that some special forms can be defined as macros expanding to other special forms, but some special forms must actually be present.
E.g., one can define if in terms of cond:
(defmacro my-if (condition yes no)
`(cond (,condition ,yes)
(t ,no)))
and vice versa (much more complicated - actually, cond is a macro, usually expanding into a sequence of ifs).
PS. Note that the distinction between system-supplied macros and special operators, while technically crisp and clear (see special-operator-p and macro-function), is ideologically blurred because
An implementation is free to implement a Common Lisp special operator
as a macro. An implementation is free to implement any macro operator
as a special operator, but only if an equivalent definition of the
macro is also provided.
sds's answer answers this question well, but there are a few more general aspects that I think are worth mentioning. As that answer and others have pointed out, if, is built into the language as a special operator, because it really is a kind of primitive. Most importantly, if is not a function.
That said, the functionality of if can be achieved using just functions and normal function calling where all the arguments are evaluated. Thus, conditionals can be implemented in the lambda calculus, on which languages in the family are somewhat based, but which doesn't have a conditional operator.
In the lambda calculus, one can define true and false as functions of two arguments. The arguments are presumed to be functions, and true calls the first of its arguments, and false calls the second. (This is a slight variation of Church booleans which simply return their first or second argument.)
true = λ[x y].(x)
false = λ[x y].(y)
(This is obviously a departure from boolean values in Common Lisp, where nil is false and anything else is true.) The benefit of this, though, is that we can use a boolean value to call one of two functions, depending on whether the boolean is true or false. Consider the Common Lisp form:
(if some-condition
then-part
else-part)
If were were using the booleans as defined above, then evaluating some-condition will produce either true or false, and if we were to call that result with the arguments
(lambda () then-part)
(lambda () else-part)
then only one of those would be called, so only one of then-part and else-part would actually be evaluated. In general, wrapping some forms up in a lambda is a good way to be able delay the evaluation of those forms.
The power of the Common Lisp macro system means that we could actually define an if macro using the types of booleans described above:
(defconstant true
(lambda (x y)
(declare (ignore y))
(funcall x)))
(defconstant false
(lambda (x y)
(declare (ignore x))
(funcall y)))
(defmacro new-if (test then &optional else)
`(funcall ,test
(lambda () ,then)
(lambda () ,else)))
With these definitions, some code like this:
(new-if (member 'a '(1 2 3))
(print "it's a member")
(print "it's not a member"))))
expands to this:
(FUNCALL (MEMBER 'A '(1 2 3)) ; assuming MEMBER were rewritten
(LAMBDA () (PRINT "it's a member")) ; to return `true` or `false`
(LAMBDA () (PRINT "it's not a member")))
In general, if there is some form and some of the arguments aren't getting evaluated, then the (car of the) form is either a Common Lisp special operator or a macro. If you need to write a function where the arguments will be evaluated, but you want some forms not to be evaluated, you can wrap them up in lambda expressions and have your function call those anonymous functions conditionally.
This is a possible way to implement if, if you didn't already have it in the language. Of course, modern computer hardware isn't based on a lambda calculus interpreter, but rather on CPUs that have test and jump instructions, so it's more efficient for the language to provide if a primitive and to compile down to the appropriate machine instructions.
Lisp syntax is regular, much more regular than other languages, but it's still not completely regular: for example in
(let ((x 0))
x)
let is not the name of a function and ((x 0)) is not a bad form in which a list that is not a lambda form has been used in the first position.
There are quite a few "special cases" (still a lot less than other languages, of course) where the general rule of each list being a function call is not followed, and if is one of them. Common Lisp has quite a few "special forms" (because absolute minimality was not the point) but you can get away for example in a scheme dialect with just five of them: if, progn, quote, lambda and set! (or six if you want macros).
While the syntax of Lisp is not totally uniform the underlying representation of code is however quite uniform (just lists and atoms) and the uniformity and simplicity of representation is what facilitates metaprogramming (macros).
"Lisp has no syntax" is a statement with some truth in it, but so it's the statement "Lisp has two syntaxes": one syntax is what uses the reader to convert from character streams to s-expressions, another syntax is what uses the compiler/evaluator to convert from s-expressions to executable code.
It's also true that Lisp has no syntax because neither of those two levels is fixed. Differently from other programming languages you can customize both the first step (using reader macros) and the second step (using macros).
It would not make any sense to do so. Example: (if (ask-user-should-i-quit) (quit) (continue)). Should that quit, even though the user does not want to?
IF is not a function in Lisp. It is a special built-in operator. Lisp a several built-in special operators. See: Special Forms. Those are not functions.
The arguments are not evaluated as for functions, because if is a special operator. Special operators can be evaluated in any arbitrary way, that's why they're called special.
Consider e.g.
(if (not (= x 0))
(/ y x))
If the division was always evaluated, there could be a division by zero error which obviously was not intended.
If isn't a function, it's a special form. If you wanted to implement similar functionality yourself, you could do so by defining a macro rather than a function.
This answer applies to Common Lisp, but it'll probably the same for most other Lisps (though in some if may be a macro rather than a special form).
I'm familiar with Emacs Lisp, but not Common (or any other) Lisp. Some Lisp programmers suggest (e.g. A basic function for emacs) that it's good to use #' in front of function arguments in Lisp code. For example:
(mapc #'my-fun '(1 2 3))
In Emacs Lisp, I believe that this is equivalent to
(mapc 'my-fun '(1 2 3))
From the elisp manual, section 12.7.
The read syntax #' is a short-hand for using function. The
following forms are all equivalent:
(lambda (x) (* x x))
(function (lambda (x) (* x x)))
#'(lambda (x) (* x x))
and the help for function
function is a special form in eval.c.
(function ARG)
Like quote, but preferred for objects which are functions. In byte
compilation, function causes its argument to be compiled. quote
cannot do that.
So it seems like a potential optimization, but no more. Moreover, coming from an ML/Haskell background, it seems strange to treat a function differently from any other data.
Question:
Do you agree that #' should be used in emacs-lisp function arguments?
(A brief explanation of why they're needed in Common Lisp would be great as well.)
Notes:
I thought it may read a different cell when the #' is omitted (value vs function). But
this seems wrong because the documentation for function doesn't say anything about grabbing the function cell. This is achieved by using symbol-function.
Related questions are
The #' in common lisp
Writing lambda expressions in common lisp
Why #' is used before lambda in Common Lisp?
but they seem to suggest that the #' is unnecessary, at least in lambdas.
The quote character in #'foo has nothing to do with the one in 'foo.
#'foo is replaced at read time by (function foo). When that is compiled and executed, it looks up the functional definition named by foo (by defun, flet, labels or similar).
'foo is replaced at read time by (quote foo). When that is compiled and executed, it is simply replaced by the symbol foo.
Funcall and apply (and thus generally higher order functions) take function designators as arguments. A function designator can be a function or a symbol naming a function, so both #'foo and 'foo are function designators.
Therefore, the forms 'foo and #'foo seem interchangable at first glance. However, the lookup of the real function is done at different times—#'foo is looked up where it is invoked, while the function named by 'foo would only be looked up when it is finally applied.
If you use a function designator many times over, it is much more efficient to do the lookup just once, or even just at compile time. That can be a really big timesaver, and translates to a smoother user experience in an editor.
Take this function:
(defun sum-greater (x y z)
(> (+ x y) z))
It's my understanding that in LISP the first element in a list always represents a function to be performed on the subsequent atoms/lists. So why doesn't LISP treat the x in (x y z) as a function to be performed on y and z. Clearly this would not be desirable behavior, but it would be the expected behavior.
Presumably the function that defines defun somehow overrides the standard LISP evaluation of a list? If so, could you detail this?
Thanks
IIRC in Common Lisp at least defun is a macro (HyperSpec), meaning it may define any evaluation strategy whatsoever for its arguments.
defun is special because it is a macro. And since macros can be implementation dependent, all sorts of black magic can happen beneath the hood.
Lisp HyperSpec (Common Lisp) says, and I quote: "None of the arguments are evaluated at macro expansion time".
Your presumption is correct. Defun is commonly a special form or macro
You can download here a basic introduction into Lisp:
Common Lisp: A Gentle Introduction to Symbolic Computation, by David S. Touretzky.
Lisp and especially Common Lisp has several Lisp forms:
function calls
macro calls
special forms
DEFUN is a macro. Thus the macro defines which parts are evaluated and which not. For ANSI Common Lisp this is defined in the standard and implemented by the DEFUN macro.
defun is not a function, but a special form (or boils down to one), and for these, evaluation mechanics are different. Similar examples would be if, where one of the arguments is even discarded entirely without being evaluated at all!