; returns sign x
(defun sign-of (x)
  (if (< x 0) (return-from sign-of -1))
  (if (eq x 0) (return-from sign-of 0))
  1)

1. (sign-of 0.0) ;=> 1, not 0
2. it uses eq on a number, which has undefined result
3. it uses multiple return-froms instead of a cond or a typecase
4. cl:signum exists

Will fix this in my fork and submit a PR along with all other koan fixes.

in koans/ondition-handlers.lisp, koans always signals an error, for example

(define-test handler-bind
  ;; When a condition is signaled, all handlers whose type matches the
  ;; condition's type are allowed to execute.
  (let ((*list* '()))
    (handler-bind ((my-error #'handle-my-error)
                   (error #'handle-error)
                   (my-serious-condition #'handle-my-serious-condition))
      (signal (make-condition 'my-error)))
    (assert-equal '( :error :my-error) *list*)))

this is solved in koans-solved/condition-handlers.lisp

Fresh checkout run results in an SBCL:

error opening #P"~/lisp-koans/.koans":
  No such file or directory

I managed to get past it by creating an empty file and run into another error which after which I found out that the file .koans needs to contain a list of file names from koans/ subfolder, without the extension, e.g. ("asserts" "nil-false-empty"). I couldn't get it to work with a list of more than one item however.

What I also don't know is what should the proper contents of .koans file be? I can list all the files in koans/ but I don't know the correct order of them (if it is important).

It would be valuable to include koans on STRING-EQUAL and STRING= in equality-distinctions.lsp (especially how these functions differ from EQUAL and EQUALP).

(define-test test-reduce-basics
    "The reduce function applies uses a supplied
     binary function to combine the elements of a
     list from left to right."
  (assert-equal ___  (reduce #'+ '(1 2 3 4)))
  (assert-equal ___ (reduce #'expt '(2 3 2))))

This doc string doesn't really make sense, specifically the "function applies uses a" bit.

I was going to open a PR, but I am not actually sure what it is supposed to be. Maybe:

The reduce function combines the elements of a list, from left to right, by applying a supplied binary function to the list elements

Koan "special-forms.lsp" introduces COND and states:

the cond form is like the c switch statement

In my opinion, CASE is a closer match - at least for types that can be compared via EQL.
This limitation could be demonstrated by explaining CASE first, showing samples with numbers/keywords and progressing to strings. After showing that case does not suffice for strings, COND is introduced as a more general-purpose special form (similar to C if-else if-else if...)

What do you think?

Bonus: ECASE might also be of interest for learners.

This is stock, the asserts pass without modification:

(define-test test-adjustable-array
    "one may build arrays that can change size"
  (let ((x (make-array '(2 2) :initial-element 5 :adjustable t)))
    (assert-equal (aref x 1 0) 5)
    (assert-equal (array-dimensions x) '(2 2))
    (adjust-array x '(3 4))
    (assert-equal (array-dimensions x) '(3 4))))

line 61 Should be unwieldy?

Hi I get this error using

[anquegi@localhost lisp-koans]$ sbcl --script contemplate.lsp

Thinking about ASSERTS
ASSERT-TRUE has expanded your awareness.

         ...
     ...

Thinking about SCORING-PROJECT
TEST-SCORE-OF-AN-EMPTY-LIST-IS-ZERO has expanded your awareness.
TEST-SCORE-OF-A-SINGLE-ROLL-OF-5-IS-50 has expanded your awareness.
TEST-SCORE-OF-A-SINGLE-ROLL-OF-1-IS-100 has expanded your awareness.
TEST-SCORE-OF-MULTIPLE-1S-AND-5S-IS-THE-SUM-OF-INDIVIDUAL-SCORES has expanded your awareness.
TEST-SCORE-OF-SINGLE-2S-3S-4S-AND-6S-ARE-ZERO has expanded your awareness.
TEST-SCORE-OF-A-TRIPLE-1-IS-1000 has expanded your awareness.
TEST-SCORE-OF-OTHER-TRIPLES-IS-100X has expanded your awareness.
TEST-SCORE-OF-MIXED-IS-SUM has expanded your awareness.

; in: LAMBDA ()
; (TYPEP (MAKE-ARRAY '(5 3 33) :ELEMENT-TYPE 'VECTOR) TYPE-CHECKING::X)
;
; caught WARNING:
; Derived type of TYPE-CHECKING::X is
; (VALUES (SIMPLE-ARRAY T (5 3 33)) &OPTIONAL),
; conflicting with its asserted type
; (OR CONS SYMBOL SB-KERNEL:INSTANCE).
; See also:
; The SBCL Manual, Node "Handling of Types"

; (TYPEP (MAKE-ARRAY '(5 3 9) :ELEMENT-TYPE 'STRING) TYPE-CHECKING::X)
;
; caught WARNING:
; Derived type of TYPE-CHECKING::X is
; (VALUES (SIMPLE-ARRAY T (5 3 33)) &OPTIONAL),
; conflicting with its asserted type
; (OR CONS SYMBOL SB-KERNEL:INSTANCE).
; See also:
; The SBCL Manual, Node "Handling of Types"

; (SUBTYPEP TYPE-CHECKING::X '(SIMPLE-ARRAY ARRAY *))
;
; caught WARNING:
; Derived type of TYPE-CHECKING::X is
; (VALUES (SIMPLE-ARRAY T (5 3 33)) &OPTIONAL),
; conflicting with its asserted type
; (OR CONS SYMBOL SB-KERNEL:INSTANCE).
; See also:
; The SBCL Manual, Node "Handling of Types"

; (SUBTYPEP TYPE-CHECKING::X '(SIMPLE-ARRAY T (5 * *)))
;
; caught WARNING:
; Derived type of TYPE-CHECKING::X is
; (VALUES (SIMPLE-ARRAY T (5 3 33)) &OPTIONAL),
; conflicting with its asserted type
; (OR CONS SYMBOL SB-KERNEL:INSTANCE).
; See also:
; The SBCL Manual, Node "Handling of Types"

; (SUBTYPEP TYPE-CHECKING::X '(SIMPLE-ARRAY T (* 3 *)))
;
; caught WARNING:
; Derived type of TYPE-CHECKING::X is
; (VALUES (SIMPLE-ARRAY T (5 3 33)) &OPTIONAL),
; conflicting with its asserted type
; (OR CONS SYMBOL SB-KERNEL:INSTANCE).
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 5 WARNING conditions

Thinking about TYPE-CHECKING
TEST-CHECK-SOME-COMMON-TYPES has expanded your awareness.
TEST-GET-TYPE-WITH-TYPE-OF has expanded your awareness.
TEST-TYPE-SETS-MAY-OVERLAP has expanded your awareness.
TEST-INTEGERS-CAN-GET-REALLY-BIG has expanded your awareness.
TEST-LISP-TYPE-SYSTEM-IS-HIERARCHY has expanded your awareness.
TEST-SOME-TYPES-ARE-LISTS has expanded your awareness.
TEST-TYPE-SPECIFIER-LISTS-ALSO-HAVE-HIERARCHY has expanded your awareness.
TEST-TYPE-COERSION has expanded your awareness.
TEST-ATOMS-ARE-ANYTHING-THATS-NOT-A-CONS has expanded your awareness.
TEST-FUNCTIONP has expanded your awareness.
TEST-THERE-ARE-SOME-OTHER-TYPE-PREDICATES has expanded your awareness.
TEST-GUESS-THAT-TYPE! requires more meditation.

You have not yet reached enlightenment ...
A koan threw an error.

Please meditate on the following code:
File "koans/type-checking.lsp"
Koan "TEST-GUESS-THAT-TYPE!"
Current koan assert status is "(ERROR)"

You are now 145/183 koans and 21/27 lessons closer to reaching enlightenment

I have to do this

(assert-true (subtypep (type-of x) '(SIMPLE-ARRAY T (* 3 *))))

instead of this

(assert-true (subtypep x '(SIMPLE-ARRAY T (* 3 *))))

For the test working I have to add the function type-of, I'm not sure if it a part of the exercise or is for new sbcl implementation http://www.sbcl.org/manual/#Handling-of-Types

Thanks for this great way of learning lisp

The usual file extension for Lisp source files is .lisp. Since this project's purpose is introducing people to Lisp, it should be as idiomatic as possible.

(subtypep '(vector double-float 100) '(array number *))
In SBCL, nil
In Clisp, t

Hi. I just noticed that in the test 'test-changing-hash-tables' in 'hash-tables.lsp' you wrote "ein" meaning "one". In German "one" is "eins".

We have the koans, but we don't have the completed koans.
There's an argument to be made that people shouldn't have a
way to see these without making them themselves, but I think we should include them.

Afterwards, pulls with new koans should include the completed koans.

above

I didn't think a pull request was needed to discuss a tiny change, but perhaps line 88 of contemplate.lsp could be changed to the following:

(format t "~A requires more meditation.~%" koan-name)

For whatever reason it's jarring to always see "damaged your karma". It doesn't make sense to me I suppose. Other than that it's been a great deal of fun working through this. Thanks for taking the time to put this together.

I forgot to solve, run, and therefore test https://github.com/google/lisp-koans/blob/master/koans-solved/threads.lisp - I'll do that, likely today.

Hey guys, thank you so much for this project. It was extremely helpful in giving me an introduction to Lisp family languages. The Racket ecosystem has been lacking koans and they are now under development.

It might be worth porting some non-CL specific koans from here over there, but I want to be sure I am respecting the license: If Koans are copied from this repo and rewritten to fit its destination with a citation pointing back here, does that trigger the viral clause in Apache 2.0 or am I still free to use different terms for the racket-koans source? The GitHub summary seems to indicate that I can use different terms, but IANAL.

Forked from Clozure/ccl#308

Arguably it's not very informative, the count could change immediately after or
before retrieved and and since it's a condition variable you have no great
use of it for a CAS utility...

@Slids It does make sense. Were the koans doing The Right Thing™, then, utilizing a semaphore-count function that is effectively useless in real-life scenarios? Or was this function good if used only for illustrative purposes?

A fresh installation of clisp, and a freshly pulled lisp-koans, do not play well together. I get this result:

% clisp contemplate.lsp 
WARNING: INTERN("RACECAR"): #<PACKAGE CLOS> is locked
         Ignore the lock and proceed
*** - An array has been shortened by adjusting it while another array was
      displaced to it.

Any advice?

The usual indentation in bodies is 2 spaces. Most files in this project have sometimes 3 or 4 spaces instead.

When in doubt, refer to Peter Seibel's great introduction (http://gigamonkeys.com/book/syntax-and-semantics.html#formatting-lisp-code) and/or use SLIME on Emacs to automatically indent.

The last koan in structures.lisp talks about shallow copying at the end. It looks like this:

;; note that the copying is shallow
(let ((shallow-copy (copy-american-football-player manning-1)))
  (setf (car (nfl-guy-team manning-1)) "Giants")
  (assert-equal ___ (car (nfl-guy-team manning-1)))
  (assert-equal ___ (car (nfl-guy-team shallow-copy))))))

I expected the output the team for manning-1 to be "Giants", and the team for shallow-copy to be "Colts". However, the result is that they're both "Giants".

;; note that the copying is shallow
(let ((shallow-copy (copy-american-football-player manning-1)))
  (setf (car (nfl-guy-team manning-1)) "Giants")
  (assert-equal "Giants" (car (nfl-guy-team manning-1)))
  (assert-equal "Giants" (car (nfl-guy-team shallow-copy))))))

This looks more like deep copying, unless I'm misunderstanding something...

I'm using SBCL: SBCL 1.1.1.0.debian

Great work, but I think I found an error:

(make-array '4 :element-type 'bit) makes something like #*0000 not #*0011

Altough I'm not 100% confident, it doesn't seem possible to make this test pass by just writing inside the __

(define-test write-your-own-let-statement
    "fix the let statement to get the tests to pass"
  (setf a 100)
  (setf b 23)
  (setf c 456)
  (let ((a 0)
        (b __)
        (c __))
    (assert-equal a 100)
    (assert-equal b 200)
    (assert-equal c "Jellyfish"))
  (let* ((a 0))
    (assert-equal a 121)
    (assert-equal b 200)
    (assert-equal c (+ a (/ b a)))))

macros.lsp: test-log-form-and-value

The following macro fails the first test (which checks if the log is empty to start with).

(defvar *log-with-value* nil)

;; you must write this macro
(defmacro log-form-with-value (form)
  "records the body form, and the form's return value
    to the list *log-with-value* and then evalues the body normally"
`(let ((logform nil)
            (retval ,form))
    (push '(:form ,form  :value ,(eval form)) *log-with-value*)
    retval))

    (define-test test-log-form-and-value
    "log should start out empty"
        (assert-equal nil *log-with-value*)  => FAIL
      .....) => (FAIL PASS FAIL PASS PASS FAIL PASS PASS)

When I throw in a print statement within the test, it says that log-with-value is set to:
((:FORM (- 2013 1978) :VALUE 35))

Which would be the last value logged (hinting that the value is being carried over from the last time the test was ran).

By throwing a setf at the begginning of the test, ALL of the tests pass:

 (define-test test-log-form-and-value
        (setf *log-with-value* nil)
    "log should start out empty" 
        (assert-equal nil *log-with-value*)  => PASS
      .....) => (PASS PASS PASS...)

I had a similar issue with other koans (though I don't remember which specifically). In those instances removing the print statements made the tests pass. However, this is not the case for this particular test. So I'm not sure if it's my macro or the test that is incorrect.

INCORRECT-FUNCTION-X in Line 77 may change to WRONG-FUNCTION-X to match the code below:

(define-test test-mapcar-and-reduce
    "mapcar and reduce are a powerful combination.
     insert the correct function names, instead of INCORRECT-FUNCTION-X
     to define an inner product."
  (defun inner (x y)
    (reduce #'+ (mapcar #'* x y)))
  (assert-equal 32 (inner '(1 2 3) '(4 5 6)))
  (assert-equal 310 (inner '(10 20 30) '(4 3 7))))

I am sorry for posting things like that, I now start learning how to use GitHub. There is some way to send this code directly but I don't know how.

In special-froms.lsp there is a koan like that.

(define-test write-your-own-let-statement
"fix the let statement to get the tests to pass"
(setf a 100)
(setf b 23)
(setf c 456)
(let ((a 0)
(b __)
(c __))
(assert-equal a 100)
(assert-equal b 200)
(assert-equal c "Jellyfish"))
(let* ((a 0))
(assert-equal a 121)
(assert-equal b 200)
(assert-equal c (+ a (/ b a)))))

After thinkig about it and check one solution posted on GitHub I think that correct form is something like code bellow.
(define-test write-your-own-let-statement
"fix the let statement to get the tests to pass"
(setf a 100)
(setf b 23)
(setf c 456)
(let ((a __)
(b __)
(c __))
(assert-equal a 100)
(assert-equal b 200)
(assert-equal c "Jellyfish"))
(let* ((a __)
(b __)
(c __))
(assert-equal a 121)
(assert-equal b 200)
(assert-equal c (+ a (/ b a)))))

In koans/vectors.lsp, line#19, '?' is missing.

(true-or-false ___ (typep #(1 11 111) 'vector))
->
(true-or-false? ___ (typep #(1 11 111) 'vector))

Related to #72 --- this issue also occurs with clisp in Linux:

cat /proc/version

Linux version 4.15.0-45-generic (buildd@lgw01-amd64-031) (gcc version                                                                         
 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #48-Ubuntu SMP Tue Jan 29 16:28:13 U                                                                         
TC 2019

value of most-positive-fixnum is 281474976710655 on this architecture.

When I try to load contemplate.lsp with Armed Bear Common Lisp I get the error message that __ symbol is already defined in package :cl-user. I needed to move (use-package :lisp-unit) within (in-package :lisp-koans) in order to get things working. Does this break loading contemplate.lsp with sbcl, clisp, ccl, gcl?

My complaint is that when going through the koans in order of their appearance on the meditate-linux.sh script, scoring-project.lisp kind of comes out of left field in open endedness and complexity. And the bundled solution uses lots of forms that the user is not previously familiar with: '(sort copy-list search remove). It seems like this lesson should come later, or have some more koans with these keywords come beforehand. To give the user a better chance to complete it without having to look at the solution.

log-form takes &body parameters and tries to splice them into retval. This works if given only one form, but fails if given more.

(log-form (* 2 23 43)) ;=> (let ((retval (* 2 23 43))) ...
(log-form (* 2 23 43) (+ 1 1)) ;=> (let ((retval (* 2 23 43) (+ 1 1))) ... 

I don't see why log-form takes &body in the first place. The name itself says "form", so maybe it should just be changed to take a single parameter.

The following section of the test appears to have issues in common lisp.

Compilation command:
cd ~/lisp-koans && clisp -q -norc -ansi contemplate.lsp

relevant code: lines 38-44:

(let ((sum 0))
"write your own dolist here to calculate the sum of some-primes"
"you may be interested in investigating the 'incf' function"
; (dolist ...)
(assert-equal 999607602 sum)
))

If I compile as-is, the result is:

Please meditate on the following code:
File "koans/iteration.lsp"
Koan "TEST-DOLIST"
Current koan assert status is "(ERROR)"

... this persists even when the solution is correct.

However, if I comment out the "you may be interested in..." line, the result is
Please meditate on the following code:
File "koans/iteration.lsp"
Koan "TEST-DOLIST"
Current koan assert status is "(PASS PASS FAIL)"

... and filling in a correct dolist works.

Note: it appears this issue is fixed by https://github.com/google/lisp-koans/pull/82/files, which is just waiting for a merge.

I have no idea how to run lisp koans.... Please help!

Hi,

why are these triangles illegal?

    (assert-error 'triangle-error (triangle 1 1 3))
    (assert-error 'triangle-error (triangle 2 4 2))

Hi, I'm learning through those koans now and I found small mistake:

in test-adjutable-arrays, after the (adjust-array x '(3 4)) the last assert is testing for uninitialized element. According to hyperspecs, the behavior here is undefined, thus probably SBCL specific.
The array after adjusting is: #2A((5 5 0 0) (5 5 0 0) (0 0 0 0)) in SBCL, that's somewhat counter intuitive, I'd expect NILs, not zeroes. It would be nice to put either a comment stating it's SBCL-specific when reading uninitialised element, or perhaps add :initial-element to that adjust-array.
Cheers.

functions.lsp:84 should be
(define-test test-key-params ()
rather than
(defun test-key-params ()
Currently it's just a function not being used.

Instead of SBCL interface. It's widely adopted portability layer for threading among CL implementers.

The assert (assert-true (typep 1234567890123456789 'fixnum)) fails on the X86 binary download available from http://sbcl.org/platform-table.html since most-positive-fixnum is equal to 536870911 in that version of SBCL. That hardcoded value would be better off being below 536870911 as the prefilled asserts should not fail (this is the only failing prefilled assert that I encountered while completing the Koans on the X86 Windows version of SBCL). Also the boundary between the fixnum and bignum types is already heavily emphasized in the following asserts in the test.

Running on a fresh version, on CLISP, outputs the following:

Thinking about ASSERTS
TEST-TRUE-OR-FALSE requires more meditation.

You have not yet reached enlightenment ...
A koan is incomplete.

Please meditate on the following code:
File "koans/asserts.lsp"
Koan "TEST-TRUE-OR-FALSE"
Current koan assert status is "(INCOMPLETE INCOMPLETE)"

You are now 0/175 koans and 0/27 lessons closer to reaching enlightenment

TEST-TRUE-OR-FALSE is the last koan of asserts.lsp

In line 94, the docs in the test test-functionp

the functionp predicate is true iff the argument is a function

iff should be if