SICP in Clojure (In Progress) | Hacker News Reader

SICP in Clojure (In Progress)

sicpinclojure.com

92 pointsalrex02121 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?

Yes

This one of the things that Microsoft got right with the CLR. That TCO is required by scheme is where I finally grokked programming language semantics -- how implementation and form are intertwined.

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?

http://en.wikipedia.org/wiki/Continuation-passing_style

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.)

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.

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.

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.)

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?

If you look at the status page, he wants to implement community features including editing.

The website runs on Drupal, which has multi user editing, revisions etc. The 'book' module (included in the default installation) is basically a wiki. So, the infrastructure is already in place.

Why JVM while there is LLVM?

btw, is there any work-in-progress implementations of arc using llvm?

Reply on news.ycombinator.com