If eval with (interaction-environment) should have access to everything that's defined within the lexical scope of when it's called, then why am I getting this error when I try to run the below code?
Welcome to DrRacket, version 6.3 [3m].
Language: R5RS; memory limit: 128 MB.
why does this work? object_function: undefined;
cannot reference undefined identifier
Code:
(define (disp x)
(display x))
(eval '(disp "why does this work?") (interaction-environment))
;The below doesn't work
((lambda ()
(define (object_function x)
(display x))
(eval '(object_function "But not this?") (interaction-environment))))
(define (object)
(define (object_function x)
(display x))
(eval '(object_function "And not this?") (interaction-environment)))
(object)
If I change it like so:
;The below does work
(define (object_function x)
(display x))
((lambda ()
(eval '(object_function "Why does it work now?") (interaction-environment))))
(define (object)
(eval '(object_function "And now?") (interaction-environment)))
(object)
Output:
Welcome to DrRacket, version 6.3 [3m].
Language: R5RS; memory limit: 128 MB.
Why does it work now?And now?
With eval by itself it works just fine, but wrap it in a defined function or a lambda and it can't find the locally defined function that is within the same scope that the eval function is called.
I may be misunderstanding how eval or interaction-environment deal with lexical scope, but if someone can shed some light on this that would be helpful.
When eval evaluates data it does so at top level. The lexical depth from where you call eval is not leaked into the evaluation. The second argument only changes between the three different global environments you can access.
define inside a procedure or let is just a fancy letrec and thus a lexical binding. It will not be available from eval. Top level define makes a global binding and it will be available from eval iff interaction-environment is used.
Implementations don't have to implement interaction-environment, as it is optional. The required environments are null-environment, that only have special forms, and scheme-report-environment, which is the initial environment of the system.
eval is a powerful feature that is usually the wrong solution. Usually you are doing it wrong if you need to use eval.
Related
Consider the make-account procedure in SICP.
(define (make-account balance)
(define (withdraw amount)
(if (>= balance amount)
(begin
(set! balance (- balance amount))
balance)
"Insufficient funds"))
(define (deposit amount)
(set! balance (+ balance amount))
balance)
(define (dispatch m)
(cond ((eq? m 'withdraw) withdraw)
((eq? m 'deposit) deposit)
(else (error "Unknown request: MAKE-ACCOUNT" m))))
dispatch)
And the example:
(define peter-acc (make-account 100))
(define paul-acc peter-acc)
And the footnote:
The phenomenon of a single computational object being accessed by more
than one name is known as aliasing. The joint bank account situation
illustrates a very simple example of an alias. ... Bugs can
occur in our programs if we forget that a change to an object may
also, as a “side effect,” change a “different” object because the two
“different” objects are actually a single object appearing under
different aliases. These so-called side-effect bugs are so difficult
to locate and to analyze that some people have proposed that
programming languages be designed in such a way as to not allow side
effects or aliasing ..."
In normal situations, I would here people say: "paul-acc refers to peter-acc".
As I understand it, peter-acc and paul-acc are really names that point to one computational object. So they are the same.
I am confused as to how it would be modeled in the environment model of evaluation. For example:
(define (f bank-account) ((bank-account 'deposit) 69))
(define peter-acc (make-account 100))
(define paul-acc peter-acc)
(f paul-acc)
I cannot do environment diagrams because my eyes are destroyed. Here's what I think the interaction should be:
make-account and f have pointers to the global environment.
(define peter-acc (make-account 100)) is evaluated. make-account creates a new environment e1. Enclosing environment is global. The internal procedures withdraw, deposit and dispatch are created and have pointers to e1. Dispatch is returned and is bound to the name peter-acc in the global environment.
(define paul-acc peter-acc) is evaluated. The name peter-acc is found in the global frame. paul-acc is bound to the dispatch procedure object in e1 because that is where peter-acc is pointing to. Therefore, Dispatch in e1 is bound to the names peter-acc and paul-acc in the global environment.
(f paul-acc) is evaluated. A new environment e2 is created by f. Enclosing environment is global. paul-acc is found in global. In e2, banck-account is bound to the dispatch procedure object in e1 because that is where paul-acc is pointing to. Therefore, peter-acc with respect to the global environment, paul-acc with respect to the global environment, and bank-acount with respect to e2 all point to the dispatch procedure in e1.
The body gets executed.
Is this all correct?
The thing that confuses me is when I encounter things like this in SICP exercises, when constructing environment diagrams, I read people on the web saying things like "bank-account refers to paul-acc. Paul-acc refers to peter-acc." Why exactly is the word "refers" used here? Does bank-account with respect to e2 actually point to the name paul-acc and not it's value?
Your points 2 to 5 are correct. In your point 1, f and make-account do not "have" pointers to global environment - they do not need to, by themselves. They are both entries, bindings, in the global environment. Both "refer to", or "point at" simple values, functions in both cases.
bank-account with respect to e2 actually points to the value to which paul-acc points (which is the same value to which peter-acc points, or refers). In Scheme, (define n1 n2) means "set up new binding in the current environment, named n1, and pointing at the value of the expression n2". If n2 happens to be a variable, its value is just what that variable's value is. That's why we're talking about Scheme's evaluation semantics.
A function call (fun arg) is evaluated by finding the value of arg expression, binding the function's parameter to this value, and then evaluating the function's body in the resulting environment:
( (lambda (param) body) arg )
=
(let ( (param arg) )
body)
When using emacs or my android app I run
(defun big (num) (setf num2 5)(little num)))
(defun little (num)(+ num2 num))
Little happily accepts num2 but when I run it in my SBCL repl (with sublimetext3) it does not.
Is this correct?
What is a workaround without creating a global variable for num2?
I could just pass a second argument (little num num2)
But this wont work when I am trying to mapcar little over a list. Because I can only have one argument when mapcaring correct?
Please read §6. Variables from Practical Common Lisp.
Unlike Emacs Lisp, Common Lisp relies on lexical scope by default (Emacs Lisp is dynamic by default). Dynamic scope (i.e. indefinite scope and dynamic extent) is provided by declaring variables special, and by convention, they are written with asterisks around their names (named "earmuffs"), like *standard-output*. You use defparameter or defvar to declare those variables. Since it has a global effect, you should never use them from inside functions; likewise, your usage of setf is not defined in Common Lisp: no variable named num2 was declared previously in the scope; besides, even if it did, using a global/special variable for local variable is bad style.
Dynamic scope
With special variables, you can for example locally rebind the standard output: the new value is only visible while the code is inside the body of the let binding:
(let ((*standard-output* *error-output*))
(print "Stream redirection"))
By default, print writes to the stream bound to *standard-output*; here, the stream is locally bound to the one given by *error-output*. As soon as you escape the let, *standard-output* reverts to its previous value (imagine there is a stack).
Lexical scope
With lexical scope, your code can only access the bindings that are visible in the text surrounding your code (and the global scope), and the extent is indefinite: it is possible to access a binding (sometimes indirectly) even after the code returns from the let:
(let ((closure
(let ((count 0))
(lambda () (print (incf count))))))
(funcall closure)
(funcall closure))
;; prints:
;; 1
;; 2
The lambda expression creates a closure, which captures the variable named count. Every time you call it, it will increase the count variable and print it. If you evaluate the same code another time, you define another closure and create another variable, with the same name.
Mapcar
Because I can only have one argument when mapcaring correct?
Not exactly; the function called by mapcar should be able to accept at least as many elements as the number of lists that are given to it (and it should also not require more mandatory arguments):
(mapcar (lambda (x y) (* x y))
'(1 2 3)
'(0 3 6))
=> (0 6 18)
(mapcar #'list '(1 2) '(a b) '(+ /))
=> ((1 a +) (2 b /))
The function can also be a closure, and can use special variables.
... with a closure
(defun adder (x)
(lambda (y) (+ x y)))
(mapcar (adder 10) '(0 1 2))
=> (10 11 12)
The adder functions takes a number x and returns a closure which accepts a number y and returns (+ x y).
... with a special variable
If you prefer dynamic scope, use earmuffs and give it a meaningful name:
(defparameter *default-offset* 0)
... and define:
(defun offset (x)
(+ x *default-offset*))
You can then mapcar too:
(let ((*default-offset* 20))
(mapcar #'offset '(1 2 3)))
=> (21 22 23)
As said by jkiiski in comments, you can also declare special variables with (declare (special ...)) where you usually put declarations (when entering a let, a defun, ...). You could also use the special operator progv. This can be useful to have "invisible" variables that are only known by a set of functions to exchange information. You rarely need them.
(declare ^:dynamic symbol-table)
(defn answer []
(prn "blah")
(binding [symbol-table {:answer 42}]
(-> "[:h1 (:answer symbol-table)]" read-string eval)))
The above code runs as expected when executed at the repl. it returns
cpress.hsp> (answer)
"blah"
[:h1 42]
However, when it is executed in a thread spawn by http-kit, I get an unable to resolve symbol
Exception in thread "Thread-43"
java.lang.RuntimeException: Unable to resolve symbol: symbol-table in this context, compiling:(NO_SOURCE_PATH:0:0)
at clojure.lang.Compiler.analyze(Compiler.java:6792)
at clojure.lang.Compiler.analyze(Compiler.java:6729)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3874)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7005)
at clojure.lang.Compiler.analyze(Compiler.java:6773)
to simulate this at the repl spawn a thread to run the answer function
(.. (Thread. answer) start)
Why does this happen and how to fix it?
Some experimentation shows that it can't find the symbol due to namespace.
for example, instead of getting the expression from read-string, i put in a literal
(defn answer2 []
(binding [symbol-table {:answer 42}]
(prn (eval `[:h1 (:answer symbol-table)])) ;;works
;;(eval '[:h1 (:answer symbol-table)]) ;; does not works
))
the first eval uses syntax quoting which works, but when i use regular quoting it doesn't work. syntax quoting resolves namespace while regular quoting does not. if read-string returned an expression with namespace qualified symbols then it would solve my problem I think, but read-string does not
When you run eval, unqualified symbols in the form are resolved in the current namespace at runtime (not that of the namespace where the function is defined).
To solve this, you can create a version of eval with the namespace bound to the one you need:
(defn local-eval [x]
(binding [*ns* (find-ns 'my-namespace)]
(eval x)))
(Obviously you need to change my-namespace to reflect the right name). Then you use that instead:
(defn answer []
(binding [symbol-table {:answer 42}]
(-> "[:h1 (:answer symbol-table)]" read-string local-eval)))
Why won't this piece of code work?
(setf x '(foo bar (baz)))
(labels
((baz () (print "baz here")))
(baz) ;works
(eval (third x))) ;fails with the below message
*** - EVAL: undefined function BAZ
I'm using GNU CLISP.
In Common Lisp, eval evaluates its argument in a null lexical environment, so your lexically bound function baz can't be found.
While the Common Lisp standard doesn't provide a portable way to access the lexical environment and invoke eval with it, your implementation might have this functionality. For example, in CLISP:
cs-user> (setf x '(foo bar (baz)))
(foo bar (baz))
cs-user> (labels ((baz () (print "baz here")))
(eval-env (third x) (the-environment)))
"baz here"
"baz here"
cs-user>
See geocar's answer for other approaches.
Because common lisp doesn't have special functions.
Check the description of EVAL:
Evaluates form in the current dynamic environment and the null lexical environment.
Since the lexical environment is empty, your baz function (defined by labels) isn't accessible. You'd think you could fix this by putting baz in the dynamic environment (you might want something like (declare (special baz)) or (declare (special (function baz))) or something like this) but alas: there's no way to do this.
You could simulate it yourself by creating:
(defvar baz* nil)
(defun baz (&rest args) (apply baz* args))
You then need to dynamically set baz* instead of using labels:
(setf x '(foo bar (baz)))
(let ((baz* (lambda () (print "baz here"))))
(eval (third x)))
The reason why is just some hard bits about optimisation leaking into the spec. Basically, every function-call would need some stubbing unless the compiler could prove that the function would never get defined dynamically swizzleable. That's hard to do efficiently, and it's not something most CL programmers ever did, so the spec-writers simply forbade it.
As you can see, and as with most things in CL, you can easily get it yourself if you need it. However. Given that most CL programmers never do this, you may want to re-examine why you're trying to do things this way.
Suppose I have some function which returns a struct:
(struct layer (points lines areas))
(define (build-new-layer height)
...
(layer list-a list-b list-c))
I want to keep track of the last returned result something like:
(define top-side (build-new-layer 0)) ; store the first result
...
(set! top-side (build-new-layer 0.5)) ; throw away the first result and store the new one
However, for that particular code I get the error:
set!: assignment disallowed;
cannot modify a constant
constant: top-side
Please, tell me what would be the right way to do what I want
What language are you using? it seems it's a matter of configuration, because in principle what you're doing should work. Go to the "choose language" window (Ctrl+L in Windows), click on "show details" and see if one of the options of the language currently in use disallows redefinition of variables. Alternatively, try using a different language.
Depending on where exactly you're going to use the stored result (I can't tell from the code in the question), you could pass it around as function parameters, in such a way that using a global variable is no longer necessary. This might be a better idea, relying on global state and mutation (the set! operation) is discouraged in Scheme.
If you always want to keep around the last layer, then you might prefer setting the last-layer every time one is built. Like this.
(define last-layer #f)
(define build-new-layer
(let ((save-layer #f))
(lambda (height)
(let ((new-layer (layer list-a ...)))
(set! last-layer save-layer)
(set! save-layer new-layer)
new-layer))))
Note: if the real problem is the 'constant-ness' of last-layer then build yourself a little abstraction as:
(define-values (last-layer-get last-layer-set!)
(begin
(define last-layer-access
(let ((last-layer #f))
(lambda (type . layer)
(case type
((get) last-layer)
((set) (set! last-layer (car layer)))))))
(values (lambda () (last-layer-access 'get))
(lambda (layer) (last-layer-access 'set layer))))