weird GC behaviour with CMUCL - lisp

Why is this code overflowing the heap with CMUCL? Even if i give it 400MB memory (setq extensions:*bytes-consed-between-gcs* 400000000) CMUCL will still choke on it.
; [GC threshold exceeded with 12,012,544 bytes in use. Commencing GC.]
; [GC completed with 188,064 bytes retained and 11,824,480 bytes freed.]
; [GC will next occur when at least 400,188,064 bytes are in use.]
; [GC threshold exceeded with 400,202,280 bytes in use. Commencing GC.]
; [GC completed with 207,120 bytes retained and 399,995,160 bytes freed.]
; [GC will next occur when at least 400,207,120 bytes are in use.]
This code runs ok with CCL and SBCL, though i havent looked at their memory usage.
Is this a bug in CMUCL?? I believe all these func's are tail recursive.
(defun sqrt-iter (guess x)
(if (good-enough? guess x)
guess
(sqrt-iter (improve guess x)
x)))
(defun improve (guess x)
(average guess (/ x guess)))
(defun average (x y)
(/ (+ x y) 2))
(defun good-enough? (guess x)
(< (abs (- (* guess guess) x)) 0.001))
(defun mysqrt (x)
(sqrt-iter 1.0 x))
(defun zint (x acc step)
(setq num-iter (+ 1 num-iter))
(if (>= x 10000.0)
acc
(zint (+ x step)
(+ acc (* step (mysqrt x)))
step)))
(setq num-iter 0)
(format t "result=~A; iterations=~A~%" (zint 0.0 0.0 .001) num-iter)
(quit)
EDIT:
Yes, CMUCL definitely conses a lot and unnecessarily. Try this simple example:
$ ~/cmucl/bin/lisp
...
* (defun foo () (bar))
FOO
* (defun bar () (foo))
BAR
* (foo)
; [GC threshold exceeded with 12,009,008 bytes in use. Commencing GC.]
; [GC completed with 111,816 bytes retained and 11,897,192 bytes freed.]
; [GC will next occur when at least 12,111,816 bytes are in use.]
; [GC threshold exceeded with 12,120,912 bytes in use. Commencing GC.]
; [GC completed with 120,016 bytes retained and 12,000,896 bytes freed.]
; [GC will next occur when at least 12,120,016 bytes are in use.]
; [GC threshold exceeded with 12,133,576 bytes in use. Commencing GC.]

There are two functions which are 'tail recursive': sqr-iter and zint.
General advice:
To let the compiler optimize these, the DEBUG optimization level needs to be 2 or less.
You can see if the compiler generates tail recursive code by disassembling them. Use the function disassemble.
The GC invocation itself is not a problem. Most implementations don't print anything on GC. CMUCL prints it by default (IIRC). CMUCL may allocate huge amounts of floats for un-optimized code - which then might cause a lot of GCs.
Only if CMUCL has a stack overflow you would see that the tail call optimization is not working. GCs themselves only show large amounts of consing.
So to debug your problem you need first to see if the code is compiled with tail call optimization on. You can disassemble the code. Another option is to put the code while running into the debugger and then by looking at the stack backtrace. On the stack there should not be a large number of recursive calls - they would be replaced by jumps.
If the code is running with constant stack space, then you need to look at the allocation of floats. You would need to check then that the code does not allocate too much floats.

I think it depends on the settings
... This is SBCL which is related.
* (declaim (optimize (speed 0) (compilation-speed 0) (safety 3) (debug 3)))
* (defun foo () (bar))
* (defun bar () (foo))
* (foo)
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution
INFO: Control stack guard page reprotected
#<sb-kernel::control-stack-exhausted {1002DBD4D3}>
but if you tell it you want it to go fast and not worry about debugging... it does better
(declaim (optimize (speed 3) (compilation-speed 0) (safety 1) (debug 0)))
(defun foo () (bar))
(defun bar () (foo))
(foo) ;;; CPU topped out, but no stack issues or garbage collecting

Related

scheme continuations for dummies

For the life of me, I can't understand continuations. I think the problem stems from the fact that I don't understand is what they are for. All the examples that I've found in books or online are very trivial. They make me wonder, why anyone would even want continuations?
Here's a typical impractical example, from TSPL, which I believe is quite recognized book on the subject. In english, they describe the continuation as "what to do" with the result of a computation. OK, that's sort of understandable.
Then, the second example given:
(call/cc
(lambda (k)
(* 5 (k 4)))) => 4
How does this make any sense?? k isn't even defined! How can this code be evaluated, when (k 4) can't even be computed? Not to mention, how does call/cc know to rip out the argument 4 to the inner most expression and return it? What happens to (* 5 .. ?? If this outermost expression is discarded, why even write it?
Then, a "less" trivial example stated is how to use call/cc to provide a nonlocal exit from a recursion. That sounds like flow control directive, ie like break/return in an imperative language, and not a computation.
And what is the purpose of going through these motions? If somebody needs the result of computation, why not just store it and recall later, as needed.
Forget about call/cc for a moment. Every expression/statement, in any programming language, has a continuation - which is, what you do with the result. In C, for example,
x = (1 + (2 * 3));
printf ("Done");
has the continuation of the math assignment being printf(...); the continuation of (2 * 3) is 'add 1; assign to x; printf(...)'. Conceptually the continuation is there whether or not you have access to it. Think for a moment what information you need for the continuation - the information is 1) the heap memory state (in general), 2) the stack, 3) any registers and 4) the program counter.
So continuations exist but usually they are only implicit and can't be accessed.
In Scheme, and a few other languages, you have access to the continuation. Essentially, behind your back, the compiler+runtime bundles up all the information needed for a continuation, stores it (generally in the heap) and gives you a handle to it. The handle you get is the function 'k' - if you call that function you will continue exactly after the call/cc point. Importantly, you can call that function multiple times and you will always continue after the call/cc point.
Let's look at some examples:
> (+ 2 (call/cc (lambda (cont) 3)))
5
In the above, the result of call/cc is the result of the lambda which is 3. The continuation wasn't invoked.
Now let's invoke the continuation:
> (+ 2 (call/cc (lambda (cont) (cont 10) 3)))
12
By invoking the continuation we skip anything after the invocation and continue right at the call/cc point. With (cont 10) the continuation returns 10 which is added to 2 for 12.
Now let's save the continuation.
> (define add-2 #f)
> (+ 2 (call/cc (lambda (cont) (set! add-2 cont) 3)))
5
> (add-2 10)
12
> (add-2 100)
102
By saving the continuation we can use it as we please to 'jump back to' whatever computation followed the call/cc point.
Often continuations are used for a non-local exit. Think of a function that is going to return a list unless there is some problem at which point '() will be returned.
(define (hairy-list-function list)
(call/cc
(lambda (cont)
;; process the list ...
(when (a-problem-arises? ...)
(cont '()))
;; continue processing the list ...
value-to-return)))
Here is text from my class notes: http://tmp.barzilay.org/cont.txt. It is based on a number of sources, and is much extended. It has motivations, basic explanations, more advanced explanations for how it's done, and a good number of examples that go from simple to advanced, and even some quick discussion of delimited continuations.
(I tried to play with putting the whole text here, but as I expected, 120k of text is not something that makes SO happy.
TL;DR: continuations are just captured GOTOs, with values, more or less.
The exampe you ask about,
(call/cc
(lambda (k)
;;;;;;;;;;;;;;;;
(* 5 (k 4)) ;; body of code
;;;;;;;;;;;;;;;;
)) => 4
can be approximately translated into e.g. Common Lisp, as
(prog (k retval)
(setq k (lambda (x) ;; capture the current continuation:
(setq retval x) ;; set! the return value
(go EXIT))) ;; and jump to exit point
(setq retval ;; get the value of the last expression,
(progn ;; as usual, in the
;;;;;;;;;;;;;;;;
(* 5 (funcall k 4)) ;; body of code
;;;;;;;;;;;;;;;;
))
EXIT ;; the goto label
(return retval))
This is just an illustration; in Common Lisp we can't jump back into the PROG tagbody after we've exited it the first time. But in Scheme, with real continuations, we can. If we set some global variable inside the body of function called by call/cc, say (setq qq k), in Scheme we can call it at any later time, from anywhere, re-entering into the same context (e.g. (qq 42)).
The point is, the body of call/cc form may contain an if or a condexpression. It can call the continuation only in some cases, and in others return normally, evaluating all expressions in the body of code and returning the last one's value, as usual. There can be deep recursion going on there. By calling the captured continuation an immediate exit is achieved.
So we see here that k is defined. It is defined by the call/cc call. When (call/cc g) is called, it calls its argument with the current continuation: (g the-current-continuation). the current-continuation is an "escape procedure" pointing at the return point of the call/cc form. To call it means to supply a value as if it were returned by the call/cc form itself.
So the above results in
((lambda(k) (* 5 (k 4))) the-current-continuation) ==>
(* 5 (the-current-continuation 4)) ==>
; to call the-current-continuation means to return the value from
; the call/cc form, so, jump to the return point, and return the value:
4
I won't try to explain all the places where continuations can be useful, but I hope that I can give brief examples of main place where I have found continuations useful in my own experience. Rather than speaking about Scheme's call/cc, I'd focus attention on continuation passing style. In some programming languages, variables can be dynamically scoped, and in languages without dynamically scoped, boilerplate with global variables (assuming that there are no issues of multi-threaded code, etc.) can be used. For instance, suppose there is a list of currently active logging streams, *logging-streams*, and that we want to call function in a dynamic environment where *logging-streams* is augmented with logging-stream-x. In Common Lisp we can do
(let ((*logging-streams* (cons logging-stream-x *logging-streams*)))
(function))
If we don't have dynamically scoped variables, as in Scheme, we can still do
(let ((old-streams *logging-streams*))
(set! *logging-streams* (cons logging-stream-x *logging-streams*)
(let ((result (function)))
(set! *logging-streams* old-streams)
result))
Now lets assume that we're actually given a cons-tree whose non-nil leaves are logging-streams, all of which should be in *logging-streams* when function is called. We've got two options:
We can flatten the tree, collect all the logging streams, extend *logging-streams*, and then call function.
We can, using continuation passing style, traverse the tree, gradually extending *logging-streams*, finally calling function when there is no more tree to traverse.
Option 2 looks something like
(defparameter *logging-streams* '())
(defun extend-streams (stream-tree continuation)
(cond
;; a null leaf
((null stream-tree)
(funcall continuation))
;; a non-null leaf
((atom stream-tree)
(let ((*logging-streams* (cons stream-tree *logging-streams*)))
(funcall continuation)))
;; a cons cell
(t
(extend-streams (car stream-tree)
#'(lambda ()
(extend-streams (cdr stream-tree)
continuation))))))
With this definition, we have
CL-USER> (extend-streams
'((a b) (c (d e)))
#'(lambda ()
(print *logging-streams*)))
=> (E D C B A)
Now, was there anything useful about this? In this case, probably not. Some minor benefits might be that extend-streams is tail-recursive, so we don't have a lot of stack usage, though the intermediate closures make up for it in heap space. We do have the fact that the eventual continuation is executed in the dynamic scope of any intermediate stuff that extend-streams set up. In this case, that's not all that important, but in other cases it can be.
Being able to abstract away some of the control flow, and to have non-local exits, or to be able to pick up a computation somewhere from a while back, can be very handy. This can be useful in backtracking search, for instance. Here's a continuation passing style propositional calculus solver for formulas where a formula is a symbol (a propositional literal), or a list of the form (not formula), (and left right), or (or left right).
(defun fail ()
'(() () fail))
(defun satisfy (formula
&optional
(positives '())
(negatives '())
(succeed #'(lambda (ps ns retry) `(,ps ,ns ,retry)))
(retry 'fail))
;; succeed is a function of three arguments: a list of positive literals,
;; a list of negative literals. retry is a function of zero
;; arguments, and is used to `try again` from the last place that a
;; choice was made.
(if (symbolp formula)
(if (member formula negatives)
(funcall retry)
(funcall succeed (adjoin formula positives) negatives retry))
(destructuring-bind (op left &optional right) formula
(case op
((not)
(satisfy left negatives positives
#'(lambda (negatives positives retry)
(funcall succeed positives negatives retry))
retry))
((and)
(satisfy left positives negatives
#'(lambda (positives negatives retry)
(satisfy right positives negatives succeed retry))
retry))
((or)
(satisfy left positives negatives
succeed
#'(lambda ()
(satisfy right positives negatives
succeed retry))))))))
If a satisfying assignment is found, then succeed is called with three arguments: the list of positive literals, the list of negative literals, and function that can retry the search (i.e., attempt to find another solution). For instance:
CL-USER> (satisfy '(and p (not p)))
(NIL NIL FAIL)
CL-USER> (satisfy '(or p q))
((P) NIL #<CLOSURE (LAMBDA #) {1002B99469}>)
CL-USER> (satisfy '(and (or p q) (and (not p) r)))
((R Q) (P) FAIL)
The second case is interesting, in that the third result is not FAIL, but some callable function that will try to find another solution. In this case, we can see that (or p q) is satisfiable by making either p or q true:
CL-USER> (destructuring-bind (ps ns retry) (satisfy '(or p q))
(declare (ignore ps ns))
(funcall retry))
((Q) NIL FAIL)
That would have been very difficult to do if we weren't using a continuation passing style where we can save the alternative flow and come back to it later. Using this, we can do some clever things, like collect all the satisfying assignments:
(defun satisfy-all (formula &aux (assignments '()) retry)
(setf retry #'(lambda ()
(satisfy formula '() '()
#'(lambda (ps ns new-retry)
(push (list ps ns) assignments)
(setf retry new-retry))
'fail)))
(loop while (not (eq retry 'fail))
do (funcall retry)
finally (return assignments)))
CL-USER> (satisfy-all '(or p (or (and q (not r)) (or r s))))
(((S) NIL) ; make S true
((R) NIL) ; make R true
((Q) (R)) ; make Q true and R false
((P) NIL)) ; make P true
We could change the loop a bit and get just n assignments, up to some n, or variations on that theme. Often times continuation passing style is not needed, or can make code hard to maintain and understand, but in the cases where it is useful, it can make some otherwise very difficult things fairly easy.

First larger (common) lisp program -> 'random' not working as expected

just for fun I wrote a simulation of the "monty hall problem" in Python. Later I experimented with Lua and decided to write it again in Lua to see how it will look in comparison. It was a quite interesting experience even though the programs looked very similar (the Lua version was slightly shorter). Lately I started to exeriment with CL and wanted to do the same thing again. However when I run it, it does not behave as expected. For some reason the erratic player (who should get a 66% chance to win) has almost the same score as the naive player (with 50 % chance to win).
Can someone please give me a hint what is going wrong? This is not a homework or something like that, just my first try to write a larger program with CL. Besides hints regarding the problem described above I would also welcome suggestions on how to improve my style. I guess that it's still pretty Python-ish (it's more or less a direct translation).
(defun choose-one (l)
"Ramdomly chooses one element of the given list"
(nth (random (length l)) l))
(defun remove-one (l)
"Randomly removes one element of the given list"
(remove (choose-one l) l))
(defun naive-player (initial-choice possible-choices)
"The naive player randomly picks one choice. Should have a 50% chance to win."
initial-choice ;keep compiler happy
(choose-one possible-choices))
(defun stubborn-player (initial-choice possible-choices)
"The stubborn player sticks with his initial choice. Should have a 33% chance to win."
possible-choices ;keep compiler happy
initial-choice)
(defun erratic-player (initial-choice possible-choices)
"The erratic player will always change his choice. Should have a 66% chance to win."
(choose-one (remove initial-choice possible-choices)))
(defun host-offer (prize possible-choices)
"The host reveals one wrong choice."
(let ((remaining (remove prize possible-choices)))
(remove (choose-one remaining) possible-choices)))
(defun one-game (playerfn choices)
"Simulates a single game with the given player. Evaluates to T if the player won."
(let ((prize (choose-one choices))
(player-choice (choose-one choices)))
(eq (funcall playerfn player-choice (host-offer prize choices)) prize)))
(defun multiple-games (num-games)
"Simulates the given number of games with all players. Evaluates to a result list."
(let ((choices '(door_a door_b door_c))
(naive-score 0)
(stubborn-score 0)
(erratic-score 0))
;(progn
(dotimes (i num-games)
;(progn
(if (one-game #'naive-player choices)
(incf naive-score))
(if (one-game #'stubborn-player choices)
(incf stubborn-score))
(if (one-game #'erratic-player choices)
(incf erratic-score)));)
(list
(list 'naive-player naive-score)
(list 'stubborn-player stubborn-score)
(list 'erratic-player erratic-score))));)
;; Run simulation and display results
(defparameter *num-games* 10000)
(format *standard-output* "--- Monty Hall ---~%")
(format *standard-output* "Simulating ~D games...~%" *num-games*)
(let ((result (multiple-games *num-games*)))
(format *standard-output* "~{~{~A score: ~D~}~%~}" result))
Output (for example):
--- Monty Hall ---
Simulating 10000 games...
NAIVE-PLAYER score: 5014
STUBBORN-PLAYER score: 3333
ERRATIC-PLAYER score: 4968
The host offer function is wrong. In the Monty Hall problem as defined the host will never open the door the player has chosen, but your program doesn't take that into account. If that is fixed the program returns expected results.

pretty printing and expansion

EDIT I'm not just asking about 'indenting' every single line of code but about "pretty printing" and/or a wider definition of "indenting", where lines would be grouped/split depending on what they contain.
Here's a function (which I wrote to solve an Euler problem but that is not the point: I could have written it differently) which I'm trying to pretty print:
Version manually indented:
(apply max
(flatten
(for [x (range 100 1000)]
(map
#(if (= (str (* x %)) (apply str (reverse (str (* x %)))))
(* x %)
0)
(range x 1000)))))
Apparently this isn't the one true Lisp indentation/printing style and, as I'd like to get good habits from the start, I tried to "pretty print" it, doing the following from Emacs' slime-repl clojure REPL:
user> (doc pprint) ;; just to show which version of pprint I'm using
clojure.pprint/pprint
...
So I tried to do:
user> (pprint '(apply max
(flatten
(for [x (range 100 1000)]
(map
#(if (= (str (* x %)) (apply str (reverse (str (* x %)))))
(* x %)
0)
(range x 1000))))))
And I got the following:
(apply
max
(flatten
(for
[x (range 100 1000)]
(map
(fn*
[p1__13958#]
(if
(=
(str (* x p1__13958#))
(apply str (reverse (str (* x p1__13958#)))))
(* x p1__13958#)
0))
(range x 1000)))))
As I understand it the #(...) notation for the lambda is a "reader macro". So how can I pretty print without triggering the expansion of macros? More generally: how can I pretty print "what I see in my text editor"?
Also, is it normal that nearly everything goes on a new line? For example:
(apply
max
(flatten
(for
[x (range 100 1000)]
(map
...
seems to be a waste of quite some vertical screen real estate. Is this the way Lisp code should be indented?
And a last related question: can Emacs be configured to "pretty print" a selected region or an entire .clj buffer?
There's no "official" way to indent lisp code, but I like the way clojure-mode indents clojure code (see below).
I don't know why pprint prints code the way it does but according to this page, it's an early release that isn't feature-complete yet.
For the emacs indentation part, you might want to take a look at clojure-mode.
The closest I have seen to a consensus is to "indent it like Emacs does", I suppose to be pollitically correct I should include the corollary "indent it like vim does". the other editors like eclipse+CCW seem to match this fairly closely. though the default pretty printer adds more newlines.
Here's what I'm currently doing:
(defn pprint-code [code]
(with-pprint-dispatch code-dispatch
(binding [*print-suppress-namespaces* true]
(pprint code))))
NOTE: Look in clojure.pprint to resolve the free-vars.
It's certainly an improvement. I still don't exactly know how to tweak *print-miser-width* and/or *print-right-margin* to get better output. YMMV. My current beef is with (auto-)gensyms - I want them demangled whilst pprinting in certain contexts.
Ideally, forms/functions could define their own formatting rules, e.g. let-bindings should always be on separate lines. I'm not aware of being able to do this with clojure.core.
For reference, see this overview.

When does Emacs Lisp's lexical-let leak memory?

I read about lexical-let's memory leak, for example here:
Are there any problems with lexical-let or other cl-macros??? - Users list for the GNU Emacs text editor - ArchiveOrange
It says:
"Note that variables bound with lexical-let are never released, even
if they are never used. Try
(loop for i from 1 to 100000 collect (lexical-let ((x i)) '()))
and watch it eat memory."
But I think this code eats memory just because the list made by loop grows.
So, I wrote a few elisp codes to check when it occurs but I could not find a example of the leak.
This is how memory grows with time when I execute the code below.
(require 'cl)
(defvar num-loop-1 30)
(defvar num-loop-2 100000)
(loop for i from 1 to num-loop-1 do
(loop for j from 1 to num-loop-2 collect
(lexical-let ((x `(,i ,j))) (lambda () x))))
It looks like there is no leak.
See more examples here:
https://gist.github.com/1703325
ADDED: This is how the first example eats memory. As I said, I think it is an artifact.
I just found this in emacs-devel:
When does Emacs Lisp's lexical-let leak memory?
So... Is it true, that "variables bound with lexical-let are never
released, even if they are never used"?
Not that I know. Of course, this code is not bug-free, but I don't know
of any concrete case that bumps into such a bug.
-- Re: lexical-let cause memory leaks?

Common Lisp Error Not Understood

I'm trying to write a number guessing game in Lisp as a time-killing project. However, when I try to load up the program using SBCL, I get the following error:
debugger invoked on a SB-C::INPUT-ERROR-IN-COMPILE-FILE in thread #<THREAD
"initial thread" RUNNING
{AA14959}>:
READ failure in COMPILE-FILE at character 477:
end of file on #<SB-SYS:FD-STREAM
for "file /home/andy/Dropbox/Programming/Common Lisp/number-game.lisp"
{B4F45F9}>
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore runtime option --load "number-game.lisp".
1: [ABORT ] Skip rest of --eval and --load options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
(SB-C::READ-FOR-COMPILE-FILE
#<SB-SYS:FD-STREAM
for "file /home/andy/Dropbox/Programming/Common Lisp/number-game.lisp"
{B4F45F9}>
477)
What does this error mean? The code is as follows, and the error appears when loading the file and calling (play) from the REPL:
;;;; number-game.lisp
;;;;
;;;; Andrew Levenson
;;;; 10/25/2010
;;;;
;;;; Simple number guessing game. User has
;;;; five guesses to determine a number between
;;;; one and one hundred, inclusive (1-100).
;;; Set global variable for the target number:
(defparameter *target* nil)
;;; Set the iterator so we may check the number of guesses
(defparameter *number-of-guesses* 0)
;;; Welcome the user
(defun welcome-user ()
(format t "Welcome to the number guessing game!~%"))
;;; Prompt for a guess
(defun prompt-for-guess ()
(format t "Please enter your guess (1-100): ")
(finish-output nil) ; nil directs finish-output to standard IO
(check-guess((read-guess)))
;;; Read in a guess
(defun read-guess ()
(let ((guess (read)))
(if (numberp guess) ; If true, return guess. Else, call prompt-for-guess
(progn
(setq *number-of-guesses* (+ *number-of-guesses* 1))
guess)
(prompt-for-guess))))
;;; Check if the guess is higher than, lower than, or equal to, the target
(defun check-guess (guess)
(if (equal guess *target*)
(equal-to)
(if (> guess *target*)
(greater-than (guess))
(if (< guess *target*)
(less-than (guess))))))
;;; If the guess is equal to the target, the game is over
(defun equal-to ()
(format t "Congratulations! You have guessed the target number, ~a!~%" *target*)
(y-or-n-p "Play again? [y/n] "))
;;; If the guess is greater than the target, inform the player.
(defun greater-than (guess)
(format t "Sorry, ~a is greater than the target.~%" guess)
(if (< *number-of-guesses* 6)
(prompt-for-guess)
(game-over)))
;;; If the guess is less than the target, inform the player.
(defun less-than (guess)
(format t "Sorry, ~a is less than the target.~%" guess)
(if (< *number-of-guesses* 6)
(prompt-for-guess)
(game-over)))
;;; If the player has run out of guesses, give them the option
;;; of playing the game again.
(defun game-over ()
(y-or-n-p "You have run out of guesses. Play again? [y/n] "))
;;; Play the game
(defun play ()
;; If it's their first time playing this session,
;; make sure to greet the user.
(unless (> *number-of-guesses* 0)
(welcome-user))
;; Reset their remaining guesses
(setq *number-of-guesses* 0)
;; Set the target value
(setq *target*
;; Random can return float values,
;; so we must round the result to get
;; an integer value.
(round
;; Add one to the result, because
;; (random 100) yields a number between
;; 0 and 99, whereas we want a number
;; from 1 to 100 inclusive.
(+ (random 100) 1)))
(if (equal (prompt-for-guess) "y")
(play)
(quit)))
(I'm fairly certain that the program doesn't work minus that one error, I'm still a complete novice when it comes to Lisp. This is just the first error I've encountered that I can't figure out on my own.)
Oh, and the issue most likely has to do with the prompt-for-guess, read-guess and check-guess functions, because those were the ones I was messing with when this error cropped up.
It looks like you didn't close enough parens on your prompt-for-guess defun.
The reader is getting to the end of the file and noticing that it has a form still open, and can't figure out where it's from.
An easy way I use to find errors like this is to have my text editor indent the region, and make sure everything lines up like I think it should.
The command in Emacs is M-x check-parens (it checks everything that needs to balance, like quotes, as well). It can be a bit mystifying if everything balances, because it does nothing in that case.
check-parens
Command: Check for unbalanced parentheses in the current buffer.
More accurately, check the narrowed part of the buffer for unbalanced
expressions ("sexps") in general. This is done according to the
current syntax table and will find unbalanced brackets or quotes as
appropriate. (See Info node `(emacs)Parentheses'.) If imbalance is
found, an error is signaled and point is left at the first unbalanced
character.
end of file during read, there is a closing parenthesis (or similar) missing. Character 477. Move the cursor in your text to 477 and check which expression it is.
Check your IDE for a command to find unbalanced expressions.
In LispWorks this would be M-x Find Unbalanced Parentheses.
SLIME should have some command for that, too.