I am still interested in the question which has been answered.
continuation in common lisp by macros — regarding an implemetation in OnLisp
What will happen if Paul Graham's assumption is correct especially when change from (A 5) to (B 1)? What is cont bound to here?
And one more confusion when the text says
=bind, is intended to be used in the same way as multiple-value-bind. It takes a list of parameters, an expression, and a body of code: the parameters are bound to the values returned by the expression, and the code body is evaluated with those bindings.
I cannot see the binding directly from the macro definition of =bind which looks like
(defmacro =bind (parms expr &body body)
`(let ((*cont* #'(lambda ,parms ,#body))) ,expr))
Does the binding happens only when =values comes in later?
The macro sets the continuation, *cont*, to be a lambda which takes all of your variables as arguments, and then evaluates the expression expr. The expression is expected to call the continuation with its final value, which can be done indirectly by calling the =values function, or directly with funcall. Unlike Scheme, where the continuation is implicitly called with the return value of any expression, you must explicitly write your code in continuation-passing style by calling *cont* or using =values instead of returning from any function.
Related
i don't know why NOT is defined as function but macro.i've heard that function call may be cache-unfriendly.
will it be better if NOT is a macro?the only reason i can think of is that a NOT function can be passed as value by adding #'.
grateful for your answers!
not has the semantics of a function: its argument is evaluated perfectly normally (unlike, say, and and so on). It should therefore be a function: macros should be used only for things which cannot semantically be functions.
Making not a function has benefits: simply because it is a function you don't need to write your own version every time you need a function with the semantics of not. Making not a function also has zero cost since the semantics of CL leave a compiler or interpreter entirely free to never actually call the function but rather generate inline code.
Indeed you can see, for instance, in the SBCL sources that this is happening: in src/code/pred.lisp you will find
(defun not (object)
"Return T if X is NIL, otherwise return NIL."
(not object))
You can do this yourself, pretty much:
(declaim (inline neg))
(defun neg (x)
(if x nil t))
(And if you are really feeling your oats define a compiler macro as well, although I can't see any strong reason to do that here.)
I have made a simple implementation of LISP using SICP metacircular evaluator as a reference, but even though I know and see the code I don't quite understand something about it. In the apply function that applies a closure to its arguments there is a piece of code that calls eval on each of it's arguments. If I quote an argument, then eval of that argument will give the raw form of that argument.
For clarity of the nature of the question and to present my current understanding of what is happening I will walk through an example.
(define f (lambda (x) (print x)))
(define g (lambda (x) (f x)))
; prints "bar" into the console
(g (quote bar))
First we call g with (quote bar) as the first parameter. The argument to g is evaluated to a symbol bar.
When g is evaluated, it passes it should evaluate it's argument and pass it to function f. But evaluating a symbol will cause a lookup from the environment, which doesn't seem to happen (if it did I should have printed an error, or something like that).
So what I want to know is why does the code print bar and not an error.
I walked through the code with the debugger and now I believe I understand. When g was called, a new environment was created with x associated with the symbol bar. And when a function is executed it's parameters are being evaluated to the things that are stored in the environment. So it's not bar that got evaluated, it's x that got evaluated to bar. And after x is evaluated there's no second-time evaluation.
The reason why quoted things appear to stay quoted is because they actually do get unquoted, but they don't get evaluated as arguments (they only get evaluated once you explicitly call eval on them).
Just do not understand the description of macro used for operators which creates context.
It seems to me that if there is a binding, macro is the only choice.
Is this cannot be achieved by other means?
What does the text below really mean?
Thanks a lot.
There is another kind of context besides a lexical environment. In the
broader sense, the context is the state of theworld, including the
values of special variables, the contents of data structures, and the
state of things outside Lisp. Operators which build this kind of
context must be defined as macros too, unless their code bodies are to
be packaged up in closures. The names of context-building macros often
begin with with-. The most commonly used macro of this type is
probably with-open-file. Its body is evaluated with a newly opened
file bound to a user-supplied variable:
(with-open-file (s "dump" :direction :output)
(princ 99 s))
......
This operator clearly has to be defined as amacro,because it binds s.
However, operators which cause forms to be evaluated in a new context
must be defined as macros anyway.
A form which needs to be executed in a new environment can be defined in two ways:
a macro which expands into the preparation of the environment and the body for the form
a function, which takes a function which is executed inside
What's not possible is this:
(this-is-some-function-with-some-file-opened (princ 99))
Above is not possible, because the princ form will be executed before the function this-is-some-function-with-some-file-opened. Argument forms are executed before the called function. The values of these argument forms will then be passed to the called function.
Thus for the functional version, the body form needs to be passed as a function, which later will be called with the necessary arguments. The macro variant will already expand into the necessary forms and place the body form inside this.
The typical macro version:
(with-open-file (s "dump" :direction :output)
(princ 99 s))
A version using a function:
(call-with-open-file
(lambda (s)
(princ 99 s))
"dump"
:direction :output)
In above one passes in the body as a function and then various parameter follow. From a functional view this is fine. But Common Lisp does not have this function in the language standard. Common Lisp provides the building blocks (OPEN, CLOSE, UNWIND-PROTECT) and the macro WITH-OPEN-FILE, which expands into code that uses the building blocks.
The drawback is that the body could be long and then the parameters are way at the bottom:
(call-with-open-file
(lambda (s)
(princ 99 s)
; 100 more lines here
)
"dump"
:direction :output)
Thus the macro version is seen as more readable in code, since all the information about the opened stream is located at the top. Note that putting the function at the end and the other parameters at the top would also not be a good option, since in Common Lisp lambda lists we have this: positional parameters come first, then optional and keyword parameters.
But in many libraries one gets both the function and the macro. The macro just expands into the function.
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 have a question concerning evaluation of lists in lisp.
Why is (a) and (+ a 1) not evaluated,
(defun test (a) (+ a 1))
just like (print 4) is not evaluated here
(if (< 1 2) (print 3) (print 4))
but (print (+ 2 3)) is evaluated here
(test (print (+ 2 3)))
Does it have something to do with them being standard library functions? Is it possible for me to define functions like that in my lisp program?
As you probably know, Lisp compound forms are generally processed from the outside in. You must look at the symbol in the first position of the outermost nesting to understand a form. That symbol completely determines the meaning of the form. The following expressions all contain (b c) with completely different meaning; therefore, we cannot understand them by analyzing the (b c) part first:
;; Common Lisp: define a class A derived from B and C
(defclass a (b c) ())
;; Common Lisp: define a function of two arguments
(defun a (b c) ())
;; add A to the result of calling function B on variable C:
(+ a (b c))
Traditionally, Lisp dialects have divided forms into operator forms and function call forms. An operator form has a completely arbitrary meaning, determined by the piece of code which compiles or interprets that functions (e.g. the evaluation simply recurses over all of the function call's argument forms, and the resulting values are passed to the function).
From the early history, Lisp has allowed users to write their own operators. There existed two approaches to this: interpretive operators (historically known as fexprs) and compiling operators known as macros. Both hinge around the idea of a function which receives the unevaluated form as an argument, so that it can implement a custom strategy, thereby extending the evaluation model with new behaviors.
A fexpr type operator is simply handed the form at run-time, along with an environment object with which it can look up the values of variables and such. That operator then walks the form and implements the behavior.
A macro operator is handed the form at macro-expansion time (which usually happens when top-level forms are read, just before they are evaluated or compiled). Its job is not to interpret the form's behavior, but instead to translate it by generating code. I.e. a macro is a mini compiler. (Generated code can contain more macro calls; the macro expander will take care of that, ensuring that all macro calls are decimated.)
The fexpr approach fell out of favor, most likely because it is inefficient. It basically makes compilation impossible, whereas Lisp hackers valued compilation. (Lisp was already a compiled language from as early as circa 1960.) The fexpr approach is also hostile toward lexical environments; it requires the fexpr, which is a function, to be able to peer into the variable binding environment of the form in which its invoked, which is a kind of encapsulation violation that is not allowed by lexical scopes.
Macro writing is slightly more difficult, and in some ways less flexible than fexprs, but support for macro writing improved in Lisp through the 1960's into the 70's to make it close to as easy as possible. Macro originally had receive the whole form and then have to parse it themselves. The macro-defining system developed into something that provides macro functions with arguments that receive the broken-down syntax in easily digestible pieces, including some nested aspects of the syntax. The backquote syntax for writing code templates was also developed, making it much easier to express code generation.
So to answer your question, how can I write forms like that myself? For instance if:
;; Imitation of old-fashioned technique: receive the whole form,
;; extract parts from it and return the translation.
;; Common Lisp defmacro supports this via the &whole keyword
;; in macro lambda lists which lets us have access to the whole form.
;;
;; (Because we are using defmacro, we need to declare arguments "an co &optional al",
;; to make this a three argument macro with an optional third argument, but
;; we don't use those arguments. In ancient lisps, they would not appear:
;; a macro would be a one-argument function, and would have to check the number
;; of arguments itself, to flag bad syntax like (my-if 42) or (my-if).)
;;
(defmacro my-if (&whole if-form an co &optional al)
(let ((antecedent (second if-form)) ;; extract pieces ourselves
(consequent (third if-form)) ;; from whole (my-if ...) form
(alternative (fourth if-form)))
(list 'cond (list antecedent consequent) (list t alternative))))
;; "Modern" version. Use the parsed arguments, and also take advantage of
;; backquote syntax to write the COND with a syntax that looks like the code.
(defmacro my-if (antecedent consequent &optional alternative)
`(cond (,antecedent ,consequent) (t ,alternative))))
This is a fitting example because originally Lisp only had cond. There was no if in McCarthy's Lisp. That "syntactic sugar" was invented later, probably as a macro expanding to cond, just like my-if above.
if and defun are macros. Macros expand a form into a longer piece of code. At expansion time, none of the macro's arguments are evaluated.
When you try to write a function, but struggle because you need to implement a custom evaluation strategy, its a strong signal that you should be writing a macro instead.
Disclaimer: Depending on what kind of lisp you are using, if and defun might technically be called "special forms" and not macros, but the concept of delayed evaluation still applies.
Lisp consists of a model of evaluation of forms. Different Lisp dialects have different rules for those.
Let's look at Common Lisp.
data evaluates to itself
a function form is evaluated by calling the function on the evaluated arguments
special forms are evaluated according to rules defined for each special operator. The Common Lisp standard lists all of those, defines what they do in an informal way and there is no way to define new special operators by the user.
macros forms are transformed, the result is evaluated
How IF, DEFUN etc. works and what they evaluated, when it is doen and what is not evaluated is defined in the Common Lisp standard.