I learn Emacs Lisp, because I want to customize my editor and to be clear I am little bit stuck with how Dynamic binding works.
Here is example:
(setq y 2)
(let ((y 1)
(z y))
(list y z))
==> (1 2)
As a result I get back => (1 2)
Please could some one explain what actually going on. I tried to explain it for my self using concept of frames where each frame create local binding, but it seems like here it works in different way.
Why it doesn't take closest value of 'y' in the nearest frame?
If could describe in details what is going here, I will be so happy.
Thanks in advance. Nick.
In emacs lisp (as in many lisps), the values that will be bound in let are computed in parallel, in the environment "outside" the let.
As an example, the following is (approximately) equivalent:
(let ((a b)
(b a))
...)
=>
(funcall (lambda (a b) ...) b a)
If you want to bind things in sequence, you should use let*, which does what you expected let to do.
Your example seems to be taken straight from the Emacs Lisp Reference. If you scroll down to let*, you'll get the explanation:
This special form is like let, but it binds each variable right after
computing its local value, before computing the local value for the
next variable. Therefore, an expression in bindings can refer to the
preceding symbols bound in this let* form. Compare the following
example with the example above for let:
(setq y 2)
⇒ 2
(let* ((y 1)
(z y)) ; Use the just-established value of y.
(list y z))
⇒ (1 1)
The problem is solved if You use let* which allows You to use the let-mentioned vars:
(setq y 2)
(let* ((y 1)
(z y))
(list y z))
==> (1 1)
The value of y you are setting in the let us only in effect in the BODY of the let, it is not yet in effect yet when you set z in the same let statement.
Related
This should be a quick one: I've been asking myself often whether there's a difference in efficiency between the LISP special functions let and let*? For instance, are they equivalent when creating only one variable?
As Barmar pointed out, there shouldn't be any performance difference in "production ready" Lisps.
For CLISP, both of these produce the same (bytecode) assembly:
(defun foo (x) (let ((a x) (b (* x 2))) (+ a b)))
(defun bar (x) (let* ((a x) (b (* x 2))) (+ a b)))
Though for non-optimizing, simple interpreters (or also compilers) there could very well be a difference, e.g. because let* and let could be implemented as simple macros, and a single lambda with multiple parameters is probably more efficient than multiple lambdas with a single parameter each:
;; Possible macro expansion for foo's body
(funcall #'(lambda (a b) (+ a b)) x (* x 2))
;; Possible macro expansion for bar's body
(funcall #'(lambda (a) (funcall #'(lambda (b) (+ a b)) (* x 2))) x)
Having multiple lambdas, as well as the (avoidable) closing over a could make the second expansion less "efficient".
When used with only one binding, then there shouldn't be any difference even then, though.
But if you're using an implementation that isn't optimizing let* (or let), then there's probably no point discussing performance at all.
There shouldn't be any performance difference. The only difference between them is the scope of the variables, which is dealt with at compile time. If there's only one variable, there's absolutely no difference.
Using DrRacket, on both linux and Mac OS, the following code gives this error
*: expects type <number> as 1st argument, given #<undefined>
but if I uncomment the (newline) at the beginning of the procedure definition, it works fine, yielding the expected value, 9.
#lang r5rs
(define (quadr x y)
;(newline)
(define xx (* x x))
(define yy (* y y))
(define xxyy (* xx yy))
(+ xx yy xxyy))
(display (quadr 1 2))
(newline)
Is this a bug in Racket's scheme interpreter, or is the language specified so that the nested invocations of (define ...) may happen out of order? If the latter is the case, where can I find the relevant bit of the language specification?
As an aside, I am very aware of the "let" construct and know that this is not the recommended way to define such a procedure. Still, I didn't expect this error.
Here's the relevant link to the R5RS specification explaining the behavior of internal definitions. Notice that in section §5.2.2 is stated that:
... it must be possible to evaluate each <expression> of every internal definition in a <body> without assigning or referring to the value of any <variable> being defined.
In other words, you can't count on a correct behavior if you define values that depend on previously defined values within the same internal definition. Use let* for this:
(define (quadr x y)
(let* ((xx (* x x))
(yy (* y y))
(xxyy (* xx yy)))
(+ xx yy xxyy)))
Or a bit more verbose, using a couple of nested lets:
(define (quadr x y)
(let ((xx (* x x))
(yy (* y y)))
(let ((xxyy (* xx yy)))
(+ xx yy xxyy))))
It's very peculiar that inserting a (newline) causes the variable definition to work for this example, but when you're dealing with undefined behavior, anything can happen. As a side note, if I use #lang racket instead of #lang r5rs, the original code works for me without the extra (newline).
I'm actually faced to a problem in Scheme. And I just don't have any idea about how to solve it. It is pretty simple to understand and I guess kind of easy for any Scheme expert. I just have to simulate the where expression of haskell with the defmac function in scheme defining a macro "operation". For example, to execute a code like the following
> (operation (+ x y)
where ([x 1]
[y (+ x 32)]))
34
I'm kind of familiar with the way to represent simple objects in scheme with macros (defmac) but now i'm really stuck with this problem.
Any help or idea would be really welcome.
Thank you in advance.
If i understand correctly you want to transform that code into something like
(let* ((x 1)
(y (+ x 32))
(+ x y))
(define-syntax operation
(syntax-rules (where)
((operation expression where body)
(let* body expression))))
Should do it, but only where "where" is right after the expression
Sounds like this should do the trick (using this defintion of defmac):
(defmac (operation expr
where (binding ...))
#:keywords where
(let* (binding ...)
expr))
It simply converts your operation form into the equivalent let*, so that your example would become:
(let* ((x 1)
(y (+ x 32)))
(+ x y))
While coding a predicate that tests whether or not a number is divisible by all integers across a certain range, I was wondering if it is possible to make rules about input, maybe through the "declare" symbol?
Code:
(defun integer-divisiblep (n m i)
(declare (integer n m i))
(do ((x m (- x 1)))
((< x n) (return t))
(when (not (integerp (/ i x)))
(return nil))))
In this case I may like to specify that the input value "n" must be smaller than "m". Is there anyway to do this with an inbuilt function? I can't seem to find what I want with the declaration-identifiers on the Hyperspec.
Also, I'm using SBCL, if that makes a difference.
Common Lisp does not provide static type checks for argument types. Some Common Lisp compilers do it as an extension, most notably CMUCL and SBCL. These static type checks use the typical declarations of variable types provided by DECLARE. You need to see the syntax of the various types to see what can be declared.
Dynamic checks at runtime are best done with CHECK-TYPE and ASSERT.
In this case I may like to specify that the input value "n" must be smaller than "m"
This is something like:
(assert (and (numberp m) (numberp n) (< n m)) (m n))
The list (m n) at the end is a list of variables which can be interactively set by the user, if the assert is violated. After entering a different value, the assertion will be checked again, until the assertion is satisfied.
I never really thought about this until I was explaining some clojure code to a coworker who wasn't familiar with clojure. I was explaining let to him when he asked why you use a vector to declare the bindings rather than a list. I didn't really have an answer for him. But the language does restrict you from using lists:
=> (let (x 1) x)
java.lang.IllegalArgumentException: let requires a vector for its binding (NO_SOURCE_FILE:0)
Why exactly is this?
Mostly readability, I imagine. Whenever bindings are needed in Clojure, a vector is pretty consistently used. A lot of people agree that vectors for bindings make things flow better, and make it easier to discern what the bindings are and what the running code is.
Just for fun:
user=> (defmacro list-let [bindings & body] `(let ~(vec bindings) ~#body))
#'user/list-let
user=> (macroexpand-1 '(list-let (x 0) (println x)))
(clojure.core/let [x 0] (println x))
user=> (list-let (x 0 y 1) (println x y))
0 1
nil
This is an idiom from Scheme. In many Scheme implementations, square brackets can be used interchangeably with round parentheses in list literals. In those Scheme implementations, square brackets are often used to distinguish parameter lists, argument lists and bindings from S-expressions or data lists.
In Clojure, parentheses and brackets mean different things, but they are used the same way in binding declarations.
Clojure tries very hard to be consistent. There is no technical reason with a list form could not have been used in let, fn, with-open, etc... In fact, you can create your own my-let easily enough that uses one instead. However, aside from standing out visibly, the vector is used consistently across forms to mean "here are some bindings". You should strive to uphold that ideal in your own code.
my guess is that it's a convention
fn used it, defn used it, loop uses.
it seems that it's for everything that resembles a block of code that has some parameters; more specific, the square brackets are for marking those parameters
other forms for blocks of code don't use it, like if or do. they don't have any parameters
Another way to think about this is that let is simply derived from lambda. These two expressions are equivalent:
((fn [y] (+ y 42)) 10)
(let [y 10] (+ 42 y))
So as an academic or instructional point, you could even write your own very rudimentary version of let that took a list as well as a vector:
(defmacro my-let [x body]
(list (list `fn[(first x)]
`~body)
(last x)))
(my-let (z 42) (* z z))
although there would be no practical reason to do this.