In lisp I can bind free variables bound in a closure like this...
(let ((x 1) (y 2) (z 3))
(defun free-variables () (+ x y z)))
(free-variables)
results in ...
6
What I want to know is if it is possible to inspect bound closure variables dynamically?
E.g.
(inspect-closure free-variables)
resulting in something like...
((x 1) (y 2) (z 3))
Thanks SO
Common Lisp
Access to the closure's internal variables is only possible from functions in the same scope (See Jeff's answer). Even those can't query somewhere for these variables. This functionality is not provided by the Common Lisp standard.
Obviously in many cases individual Common Lisp implementations know how to get this information. If you look for example at the SLIME code (a Common Lisp development environment) for GNU Emacs, the code for inspect and backtrace functionalities should provide that. The development wants to show this - for the user/programmer the Common Lisp standard does not provide that information.
You can have multiple functions inside an enclosure, so just add another function
(defun inspect-closure () (list (list 'x x) (list 'y y) (list 'z z)))
and put it inside your let statement
If you're trying to create a function that will access -any- closure then, strictly speaking, I don't think it's possible. x, y, and z are defined locally so if you want to announce them to the world it has to come from within the closure. What you COULD do is build a macro that duplicates let functionality with the added ability to return its local variables. You'll probably want to name it something different, like mylet or whatever.
Related
AND and OR are macros and since macros aren't first class in scheme/racket they cannot be passed as arguments to other functions. A partial solution is to use and-map or or-map. Is it possible to write a function that would take arbitrary macro and turn it into a function so that it can be passed as an argument to another function? Are there any languages that have first class macros?
In general, no. Consider that let is (or could be) implemented as a macro on top of lambda:
(let ((x 1))
(foo x))
could be a macro that expands to
((lambda (x) (foo x)) 1)
Now, what would it look like to convert let to a function? Clearly it is nonsense. What would its inputs be? Its return value?
Many macros will be like this. In fact, any macro that could be routinely turned into a function without losing any functionality is a bad macro! Such a macro should have been a function to begin with.
I agree with #amalloy. If something is written as a macro, it probably does something that functions can't do (e.g., introduce bindings, change evaluation order). So automatically converting arbitrary macro into a function is a really bad idea even if it is possible.
Is it possible to write a function that would take arbitrary macro and turn it into a function so that it can be passed as an argument to another function?
No, but it is somewhat doable to write a macro that would take some macro and turn it into a function.
#lang racket
(require (for-syntax racket/list))
(define-syntax (->proc stx)
(syntax-case stx ()
[(_ mac #:arity arity)
(with-syntax ([(args ...) (generate-temporaries (range (syntax-e #'arity)))])
#'(λ (args ...) (mac args ...)))]))
((->proc and #:arity 2) 42 12)
(apply (->proc and #:arity 2) '(#f 12))
((->proc and #:arity 2) #f (error 'not-short-circuit))
You might also be interested in identifier macro, which allows us to use an identifier as a macro in some context and function in another context. This could be used to create a first class and/or which short-circuits when it's used as a macro, but could be passed as a function value in non-transformer position.
On the topic of first class macro, take a look at https://en.wikipedia.org/wiki/Fexpr. It's known to be a bad idea.
Not in the way you probably expect
To see why, here is a way of thinking about macros: A macro is a function which takes a bit of source code and turns it into another bit of source code: the expansion of the macro. In other words a macro is a function whose domain and range are source code.
Once the source code is fully expanded, then it's fed to either an evaluator or a compiler. Let's assume it's fed to a compiler because it makes the question easier to answer: a compiler itself is simply a function whose domain is source code and whose range is some sequence of instructions for a machine (which may or may not be a real machine) to execute. Those instructions might include things like 'call this function on these arguments'.
So, what you are asking is: can the 'this function' in 'call this function on these arguments' be some kind of macro? Well, yes, it could be, but whatever source code it is going to transform certainly can not be the source code of the program you are executing, because that is gone: all that's left is the sequence of instructions that was the return value of the compiler.
So you might say: OK, let's say we disallow compilers: can we do it now? Well, leaving aside that 'disallowing compilers' is kind of a serious limitation, this was, in fact, something that very old dialects of Lisp sort-of did, using a construct called a FEXPR, as mentioned in another answer. It's important to realise that FEXPRs existed because people had not yet invented macros. Pretty soon, people did invent macros, and although FEXPRs and macros coexisted for a while – mostly because people had written code which used FEXPRs which they wanted to keep running, and because writing macros was a serious pain before things like backquote existed – FEXPRs died out. And they died out because they were semantically horrible: even by the standards of 1960s Lisps they were semantically horrible.
Here's one small example of why FEXPRs are so horrible: Let's say I write this function in a language with FEXPRs:
(define (foo f g x)
(apply f (g x)))
Now: what happens when I call foo? In particular, what happens if f might be a FEXPR?. Well, the answer is that I can't compile foo at all: I have to wait until run-time and make some on-the-fly decision about what to do.
Of course this isn't what these old Lisps with FEXPRs probably did: they would just silently have assumed that f was a normal function (which they would have called an EXPR) and compiled accordingly (and yes, even very old Lisps had compilers). If you passed something which was a FEXPR you just lost: either the thing detected that, or more likely it fall over horribly or gave you some junk answer.
And this kind of horribleness is why macros were invented: macros provide a semantically sane approach to processing Lisp code which allows (eventually, this took a long time to actually happen) minor details like compilation being possible at all, code having reasonable semantics and compiled code having the same semantics as interpreted code. These are features people like in their languages, it turns out.
Incidentally, in both Racket and Common Lisp, macros are explicitly functions. In Racket they are functions which operate on special 'syntax' objects because that's how you get hygiene, but in Common Lisp, which is much less hygienic, they're just functions which operate on CL source code, where the source code is simply made up of lists, symbols &c.
Here's an example of this in Racket:
> (define foo (syntax-rules ()
[(_ x) x]))
> foo
#<procedure:foo>
OK, foo is now just an ordinary function. But it's a function whose domain & range are Racket source code: it expects a syntax object as an argument and returns another one:
> (foo 1)
; ?: bad syntax
; in: 1
; [,bt for context]
This is because 1 is not a syntax object.
> (foo #'(x 1))
#<syntax:readline-input:5:10 1>
> (syntax-e (foo #'(x 1)))
1
And in CL this is even easier to see: Here's a macro definition:
(defmacro foo (form) form)
And now I can get hold of the macro's function and call it on some CL source code:
> (macro-function 'foo)
#<Function foo 4060000B6C>
> (funcall (macro-function 'foo) '(x 1) nil)
1
In both Racket and CL, macros are, in fact, first-class (or, in the case of Racket: almost first-class, I think): they are functions which operate on source code, which itself is first-class: you can write Racket and CL programs which construct and manipulate source code in arbitrary ways: that's what macros are in these languages.
In the case of Racket I have said 'almost first-class', because I can't see a way, in Racket, to retrieve the function which sits behind a macro defined with define-syntax &c.
I've created something like this in Scheme, it's macro that return lambda that use eval to execute the macro:
(define-macro (macron m)
(let ((x (gensym)))
`(lambda (,x)
(eval `(,',m ,#,x)))))
Example usage:
;; normal eval
(define x (map (lambda (x)
(eval `(lambda ,#x)))
'(((x) (display x)) ((y) (+ y y)))))
;; using macron macro
(define x (map (macron lambda)
'(((x) (display x)) ((y) (+ y y)))))
and x in both cases is list of two functions.
another example:
(define-macro (+++ . args)
`(+ ,#args))
((macron +++) '(1 2 3))
It prints 1 on the screen even though I increased its value in the function. Is there a way to call the parameter by reference so I can use it after the function call?
(defparameter a 1)
(defun foo (x)
(+ x 1))
(foo a)
(print a)
Your code doesn't contain any traces of an operator that modifies a storage location in-place. Neither the variable a nor x are subject to mutation.
The function foo returns a number that is greater than the input number by 1.
Note that a and x are distinct variables; if we were to increment x, that has no effect on a.
Numbers are not mutable objects in ANSI Lisp; if we increment a variable x with (incf x) what is happening is that the value (+ 1 x) is calculated, and this new value stored back into the x variable.
ANSI Lisp function parameters use "pass by value", like most major Lisp dialects. When (foo a) is invoked, the argument expression a is reduced to a value: it produces the value 1. This value is no longer associated with the variable. It is passed into the function without any memory of having come from a. Inside the function, a new variable x is instantiated that is local to the function; this receives a copy of the argument value: it is initialized with 1. So x has nothing to do with a; it has just received the same value.
General solution - destructive access to variable
I think, what you wanted to know is actually this:
(defparameter a 1)
(defmacro foo (x)
`(setf ,x (+ ,x 1))) ;; this macro takes the variable given for x
;; accesses its memory location using `setf`
;; and changes its value to 2
;; by increasing the accessed value by 1
(foo a) ;; a's value becomes 2
a ;; 2
However, as a beginner in common lisp, be careful to mutate wildly values around. Although I don't want to take you the joy of the power of Lisp. :)
Special solution - foo = incf
But foo (which increments a given value by 1)
is exactly incf in common lisp, because this increment by one is often needed. So for this very special case, you can just use incf.
(defparameter a 1)
a ;; => 1
(incf a) ;; incf mutates a to 2 - in exactly the way foo does
a ;; => 2 ;; a ist after that changed.
Note, there is also decf which decrements the variable by 1 - the opposite of incf.
Secial solution for global variables
But for global variables, you can use very normal defparameter to reassign the value to a:
(defparameter a 1)
(defparameter a (foo a)) ;; reassigns new value `2` to `a`
a ;; returns 2, since mutated now
Comment to the very first version:
(setf <var> <new-value>) is like a pointer access to the variable's memory location and writing to it what is given for <new-value>.
So in Lisp, you have to use a combination of defmacro and setf to imitate or actually do call-by-reference like in C or Python.
But you know from Python or C already, how un-anticipated side-effects call-by-reference can provoke. Python does by default call-by-reference due to performance reasons (because Python is interpreted and it would become very slow if doing call-by-value everytime a function is called). But with Lisp, you are/you can be at least whenever you want magnitudes faster than interpreted Python (Okay, I am simplifying - Python can of course call C function an be also super fast - however, pure Python of course would be by magnitudes slower than compiled Lisp). And you have many other possibilities to program the same thing. So don't try to imitate Python or other programs function call behaviour in Lisp - that is the wrong track.
Learn functional programming (FP) rules, which tries to not to mutate any values, but to do always call-by-value (like your function foo does). It produces 2 but leaves a the same. To reason about such programs is much more brain-friendly, thus can save you in many cases from avoidable bugs. FP is definitely sth you should learn, when dealing with Lisp btw. FP is amongst many other concepts sth what you learn when you learn Lisp - and I wouldn't want to miss it.
Destructive functions make only sense if state is really unavoidable and desired, and especially if performance is important.
I just started learning Lisp. One of the first concepts to grasp seems to be the prefix notation (i.e. instead of writing "1 + 2", write "+ 1 2"). So I am trying to work out why the 1+ function exists.
What is the reason to prefer (+ 1 2) or (1+ 2)?
Is it just syntactic sugar? Is it for code optimisation? Is it for readability?
Perhaps there are more complex function call examples that show why the 1+ function exists. Any insight would be appreciated.
Common Lisp the Language:
These are included primarily for compatibility with MacLisp and Lisp Machine Lisp. Some programmers prefer always to write (+ x 1) and (- x 1) instead of (1+ x) and (1- x).
Actually this goes back to the early Lisp. Lisp 1.5 from 1962 has it already. There the functions were called ADD1 and SUB1.
Do remember that part of Common Lisp was standardizing what many implementations already had. So, if many implementations already had a 1+ function, that could have been enough to include it. Rainer's answer quotes CLtL2 on which implementations had it (MacLisp and Lisp Machine Lisp). But why would those implementations have had it in the first place? It's useful in loops, e.g.,
(do ((x 0 (1+ x)))
((= x 10))
; ...
)
That's a place where (+ x 1) would have been fine, too. But there are lots of cases where it's handy to call that kind of function indirectly, and it's easier to (mapcar '1+ …) than to (mapcar (lambda (x) (+ 1 x)) …).
But that's really about it. Adding one (or subtracting one; there's 1- as well) to something is just such a common operation that it's handy to have a function to do it. If there's hardware support, it might be something the implementation can optimize, too. (Although the documentation does note that "implementors are encouraged to make the performance of [(1+ number) and (+ 1 number)] be the same.") Since these functions are available and widely used, they're a very good way to indicate the intent. E.g., you could make a typo and write (+ 1 x) when you meant to write (+ 2 x), but it's much less likely that you wanted to add two if you actually wrote (1+ x). These functions are idiomatic in Common Lisp (e.g., see How do I increment or decrement a number in Common Lisp?). Emacs Lisp also includes 1+ and 1-.
The language wouldn't suffer greatly if it weren't there, but it would be reimplemented many times by many different people. For instance, Racket implements add1 and sub1. (Also, see add1 function from scheme to R5RS.)
This question already has answers here:
What can you do with Lisp macros that you can't do with first-class functions?
(8 answers)
Closed 5 years ago.
In my quest to fully understand the so powerful lisp macros a question came to my mind. I know that a golden rule about macros is the one saying "Never use a macro when a function will do the work".
However reading Chapter 9 - Practical: Building a Unit Test Framework - from the book Practical Common Lisp I was introduced to the below macro whose purpose was to get rid of the duplication of the test case expression, with its attendant risk of mislabeling of results.
;; Function defintion.
(defun report-result (result form)
(format t "~:[FAIL~;pass~] ... ~a~%" result form))
;; Macro Definition
(defmacro check (form)
`(report-result ,form ',form))
OK, I understand its purpose but I could have done it using a function instead of a macro, for instance:
(setf unevaluated.form '(= 2 (+ 2 3)))
(defun my-func (unevaluated.form)
(report-result (eval unevaluated.form) unevaluated.form))
Is this only possible because the given macro is too simple ?
Furthermore, is Lisp Macro System so powerful relatively its opponents due to the code itself - like control structures, functions, etc - is represented as a LIST ?
But if it were a macro you, could have done:
(check (= 2 (+ 2 3)))
With a function, you have to do:
(check '(= 2 (+ 2 3)))
Also, with the macro the (= 2 (+ 2 3)) is actually compiled by the compiler, whereas with the function it's evaluated by the eval function, not necessarily the same thing.
Addenda:
Yes, it's just evaluating the function. Now what that means is dependent upon the implementation. Some can interpret it, others can compile and execute it. But the simple matter is that you don't know from system to system.
The null lexical environment that others are mentioning is also a big deal.
Consider:
(defun add3f (form)
(eval `(+ 3 ,form)))
(demacro add3m (form)
`(+ 3 ,form))
Then observe:
[28]> (add3m (+ 2 3))
8
[29]> (add3f '(+ 2 3))
8
[30]> (let ((x 2)) (add3m (+ x 3)))
8
[31]> (let ((x 2)) (add3f '(+ x 3)))
*** - EVAL: variable X has no value
The following restarts are available:
USE-VALUE :R1 Input a value to be used instead of X.
STORE-VALUE :R2 Input a new value for X.
ABORT :R3 Abort main loop
Break 1 [32]> :a
That's really quite damning for most use cases. Since the eval has no lexical environment, it can not "see" the x from the enclosing let.
The better substitution would be not with eval, which won't perform as expected for all cases (for example, it doesn't have access to the lexical environment), and is also overkill (see here: https://stackoverflow.com/a/2571549/977052), but something using anonymous functions, like this:
(defun check (fn)
(report-result (funcall fn) (function-body fn)))
CL-USER> (check (lambda () (= 2 (+ 2 3))))
By the way, this is how such things are accomplished in Ruby (anonymous functions are called procs there).
But, as you see, it becomes somewhat less elegant (unless you add syntax sugar) and, there's actually a bigger problem: ther's no function-body function in Lisp (although there may be non-standard ways to get at it). Overall, as you see, for this particular task the alternative solutions are substantially worse, although in some cases such approach could work.
In general, though, if you want to do something with the source code of the expressions passed into the macro (and usually this is the primary reason of using macros), functions would not be sufficient.
The report-result function needs both the source code and the result of the execution.
The macro CHECK provides both from a single source form.
If you put a bunch of check forms into the file, they are easily compiled using the usual process of compiling Lisp files. You'll get a compiled version of the checking code.
Using a function and EVAL (better use COMPILE) you would have deferred the source evaluation to a later time. It would also not be clear if it is interpreted or compiled. In case of compilation, you would then later get the compiler's checks.
Consider this piece of code:
(defvar lst '(1 1))
(defmacro get-x (x lst)
`(nth ,x ,lst))
(defun get-y (y lst)
(nth y lst))
Now let us assume that I want to change the value of the elements of the list called lst, the car with get-x and the cdr with get-y.
As I try to change the value with get-x (with setf) everything goes fine but if I try it with get-y it signals an error (shortened):
; caught STYLE-WARNING:
; undefined function: (SETF GET-STUFF)
Why does this happen?
I myself suspect that this happens because the macro simply expands and the function nth simply returns a reference to the value of an element in the list and the function on the other hand evaluates the function-call to nth and returns the value of the referenced value (sounds confusing).
Am I correct in my suspicions?
If I am correct then how will one know what is simply a reference to a value and an actual value?
The error does not happen with the macro version, because, as you assumed, the expression (setf (get-x some-x some-list) some-value) will be expanded (at compile-time) into something like (setf (nth some-x some-list) some-value) (not really, but the details of setf-expansion are complex), and the compiler knows, how to deal with that (i.e., there is a suitable setf expander defined for function nth).
However, in the case of get-y, the compiler has no setf expander, unless you provide one. The easiest way to do so would be
(defun (setf get-y) (new-value x ls) ; Note the function's name: setf get-y
(setf (nth x ls) new-value))
Note, that there are a few conventions regarding setf-expanders:
The new value is always provided as the first argument to the setf function
All setf functions are supposed to return the new value as their result (as this is, what the entire setf form is supposed to return)
There is, BTW, no such concept as a "reference" in Common Lisp (at least not in the C++ sense), though there once were Lisp dialects which had locatives. Generalized place forms (ie., setf and its machinery) work very differently from plain C++ style references. See the CLHS, if you are curious about the details.
SETF is a macro.
The idea is that to set and read elements from data structures are two operations, but usually require two different names (or maybe even something more complex). SETF now enables you to use just one name for both:
(get-something x)
Above reads a datastructure. The inverse then simply is:
(setf (get-something x) :foobar)
Above sets the datastructure at X with :FOOBAR.
SETF does not treat (get-something x) as a reference or something like that. It just has a database of inverse operations for each operation. If you use GET-SOMETHING, it knows what the inverse operation is.
How does SETF know it? Simple: you have to tell it.
For The NTH operation, SETF knows how to set the nth element. That's builtin into Common Lisp.
For your own GET-Y operation SETF does not have that information. You have to tell it. See the Common Lisp HyperSpec for examples. One example is to use DEFUN and (SETF GET-Y) as a function name.
Also note following style problems with your example:
lst is not a good name for a DEFVAR variable. Use *list* as a name to make clear that it is a special variable declared by DEFVAR (or similar).
'(1 2) is a literal constant. If you write a Common Lisp program, the effects of changing it are undefined. If you want to change a list later, you should cons it with LIST or something like COPY-LIST.