Hi Simon, I have converted a bunch of the examples from Practical Common Lisp into Clojure [1]. You might find this helpful in seeing things from a Clojure perspective.
Cheers, Stuart [1] http://blog.thinkrelevance.com/2008/9/16/pcl-clojure > Has anyone written a very simple introduction to Clojure for LISP > hackers? I've spend an evening playing with it pretty intensively, and > thus far I haven't got a thing to work. I've read > http://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_Lisp_Programmers > > , > but it hasn't helped me. > > In LISP: > > * (defun fact (n) (cond ((= 1 n) 1)(t (* n (fact (- n 1)))))) > FACT > * (fact 10) > 3628800 > > that is Common LISP, but what the hell; in Portable Standard LISP it > would have been identical except 'de' instead of 'defun'; in Scheme > it's a little different: > >> (define (fact n) (cond ((= n 1) 1)(#t (* n (fact (- n 1)))))) >> (fact 10) > 3628800 > > But the family resemblance is there... So, let's try it in Clojure: > > user=> (defun fact (n) (cond ((= n 1) 1) (t (* n (fact (- n 1)))))) > java.lang.Exception: Unable to resolve symbol: defun in this context > user=> (de fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1)))))) > java.lang.Exception: Unable to resolve symbol: de in this context > user=> (def fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1)))))) > java.lang.Exception: Too many arguments to def > user=> (defn fact [n] (cond ((= n 1) 1)(t (* n (fact (- n 1)))))) > java.lang.Exception: Unable to resolve symbol: t in this context > user=> (defn fact [n](cond ((= n 1) 1)(#t (* n (fact (- n 1)))))) > java.lang.Exception: No dispatch macro for: t > user=> (defn fact [n](cond ((= n 1) 1)(#true (* n (fact (- n 1)))))) > java.lang.Exception: No dispatch macro for: t > user=> (defn fact [n] (cond ((= n 1) 1)(true (* n (fact (- n 1)))))) > #'user/fact > > OK, what's with the funny square brackets? A sequence of forms > enclosed in square brackets is a vector, not a list. Why is the > arglist for a function a vector? For now let's accept that it is, and > pass on. > > user=> (fact 10) > java.lang.ClassCastException: java.lang.Boolean cannot be cast to > clojure.lang.IFn > > OK, so that doesn't work. As Zaphod memorably put it, 'hey, what is > truth, man?' Good question: > > user=> (true? 'true) > true > user=> (true? true) > true > user=> (true? t) > java.lang.Exception: Unable to resolve symbol: t in this context > user=> (true? 't) > false > user=> (def t 'true) > #'user/t > user=> (true? t) > true > > OK, now we know the truth, surely we can write a valid fact? > > user=> (defn fact [n] (cond ((= n 1) 1)('true (* n (fact (- n 1)))))) > #'user/fact > user=> (fact 10) > java.lang.ClassCastException: java.lang.Boolean cannot be cast to > clojure.lang.IFn > user=> (defn fact [n] (cond ((= n 1) 1)((true? 'true) (* n (fact (- n > 1)))))) > #'user/fact > user=> (fact 10) > java.lang.ClassCastException: java.lang.Boolean cannot be cast to > clojure.lang.IFn > > OK, it looks like whatever's causing the break isn't the guard on the > second cond branch. Let's for a moment try something that's purely > boolean: > > user=> (defn band [l] (cond ((nil? l) true)((true? (car l))(band (cdr > l))))) > java.lang.Exception: Unable to resolve symbol: cdr in this context > > No CDR? It's LISP, but it can't fetch the contents of the decrement > register? fifty years of LISP history tossed into the dirt. So if the > CDR isn't called the CDR, what is it called (and what's the CDADR > called)? > > user=> (defn band [l] (cond ((nil? l) true)((true? (first l))(band > (rest l))))) > #'user/band > user=> (band '(true true true)) > java.lang.ClassCastException: java.lang.Boolean cannot be cast to > clojure.lang.IFn > > OK, can we write any function at all that works? > > user=> (defn square [n] (* n n)) > #'user/square > user=> (square 4) > 16 > > Fine, so recurse up from that: > > user=> (defn power [n m] (cond ((= m 0) 1)(true (* n (power n (- m > 1)))))) > #'user/power > user=> (power 2 2) > java.lang.ClassCastException: java.lang.Boolean cannot be cast to > clojure.lang.IFn > > Arrrrggghhh... > > Getting LISP to work seamlessly inside a Java environment with easy > intercalling between LISP and Java is a very big win, and potentially > knocks things like JScheme and Armed Bear Common LISP into a cocked > hat... > > But it would be nice to be able to get started! > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
