SICP in Clojure (In Progress)(sicpinclojure.com)
sicpinclojure.com
SICP in Clojure (In Progress)
http://sicpinclojure.com/
6 comments
Rich Hickey has some interesting things to say about learning clojure via SICP.
http://groups.google.com/group/clojure/browse_thread/thread/...
Kind of off-topic, but I'm pretty surprised clojure doesn't do TCO.
Is that a JVM limitation?
Is that a JVM limitation?
Isn't the TCO problem largely a non-issue? My understanding is that if you do (defn function [...] ... (recur ...)) instead of (defn function [...] ... (function ...)) the compiler handles it for you.
There's more to tail-call optimization than simply imitating iteration using recursion.
What else is it used for?
It may help to stop thinking of it being used specifically for recursion - there can be tail calls between several functions. In cases where TCO is applicable, function A calls B, and B calls C, but since B isn't doing anything to the result, C can return directly to A. This is transitive - D, E, F, ... could all return to A as well, in constant space. It "goto"s the next function (but with arguments), and returning and popping the results off the call stack is deferred.
Rather than going into fairly abstract examples* , TCO is useful because it allows more things to be expressed in terms of function calls, without having to worry about blowing the stack. While the discussion surrounding them can be a bit overly academic, they ultimately matter because they can help make code clearer. (Not always, but you can implement clearer looping mechanisms on top of them.) A tail call is like a de-fanged goto.
* Just one: Parsing by implementing a finite state machine in function calls. See Shriram Krishnamurthi's "The Swine Before Perl" (http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...).
While the stacktrace no longer records intermediate steps, (and thus loses info useful for debugging), language implementations can typically hook tail calls to save the information when a debugging flag is on. It's not as big a problem in practice as some people think.
Rather than going into fairly abstract examples* , TCO is useful because it allows more things to be expressed in terms of function calls, without having to worry about blowing the stack. While the discussion surrounding them can be a bit overly academic, they ultimately matter because they can help make code clearer. (Not always, but you can implement clearer looping mechanisms on top of them.) A tail call is like a de-fanged goto.
* Just one: Parsing by implementing a finite state machine in function calls. See Shriram Krishnamurthi's "The Swine Before Perl" (http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...).
While the stacktrace no longer records intermediate steps, (and thus loses info useful for debugging), language implementations can typically hook tail calls to save the information when a debugging flag is on. It's not as big a problem in practice as some people think.
Also, this blog post (which did the rounds on HN a while back) was excellent for understanding it:
http://funcall.blogspot.com/2009/04/you-knew-id-say-somethin...
(It's part of a 5 part series... but you don't have to necessarily read all of them... it kind of wanders.)
http://funcall.blogspot.com/2009/04/you-knew-id-say-somethin...
(It's part of a 5 part series... but you don't have to necessarily read all of them... it kind of wanders.)
What's wrong with scheme?
Nothing, but if you're starting from scratch and know you'd have a real world use-case for Clojure sometime soon, why not learn its APIs, warts, etc rather than Scheme's?
SICP really isn't about learning Scheme, and probably shouldn't be about learning Clojure... but if someone wants to present the material in Clojure, sure, why not?
Well, SICP is hardly about Scheme itself as a language. Some features such as macros aren't mentioned at all.
It has more emphasis on programming paradigms and Scheme is just a tool to convey them. Its core is small and simple enough that you could introduce advanced topics without the need for the reader to learn the language beforehand.
It has more emphasis on programming paradigms and Scheme is just a tool to convey them. Its core is small and simple enough that you could introduce advanced topics without the need for the reader to learn the language beforehand.
Well, the many tools for _The Elements of Computing Systems_ are written in Java, which makes it easy for people to experiment.
http://www1.idc.ac.il/tecs/software.html
So perhaps a conceivable bonus is that SICP can somehow be merged with that book.
(This is not a direct answer to your question; there's nothing wrong with Scheme; just mentioning advantages of using Clojure.)
So perhaps a conceivable bonus is that SICP can somehow be merged with that book.
(This is not a direct answer to your question; there's nothing wrong with Scheme; just mentioning advantages of using Clojure.)
Related, PG's "On Lisp" to Clojure: http://blog.thinkrelevance.com/2008/12/12/on-lisp-clojure
Current status of the adaptation:
http://sicpinclojure.com/content/current-status
Seems like a Herculean task for one person.
I wonder if the author considered making it a wiki and enlisting the clojure community's help?
I wonder if the author considered making it a wiki and enlisting the clojure community's help?
Why JVM while there is LLVM?
btw, is there any work-in-progress implementations of arc using llvm?
btw, is there any work-in-progress implementations of arc using llvm?