If I'm reasonably familiar with Common Lisp, what are the main differences/advantages of Racket to pay attention to? What's the best resource (preferably online) to use to learn about Racket?
Racket's macros are unlike any other. They are better thought of as a lightweight compiler API. Check out http://www.greghendershott.com/fear-of-macros/.
Also, the whole #lang framework is a pretty unique tool for experimenting with and extending the language, see http://docs.racket-lang.org/guide/hash-languages.html. For example, used to build http://www.greghendershott.com/rackjure/.
Greg Hendershott does some great writeups, there's more to find on his site.
Really it comes down to the old CL vs scheme thing, which seems to boil down to "has almost everything you need already but is huge" vs "lets you build anything you need yourself and is tiny." However, I think this is less so with Racket because, while I haven't used it much, from what I know it's more of a batteries-included scheme used for Getting Shit Done (and does a good job of this).
If I was going to use a scheme and I didn't have the requirement of needing to embed it, I'd probably go with Racket.
http://docs.racket-lang.org/scribble/
I suppose it isn't technically such a different thing from other lisps, but like most of Racket -- it's pretty well thought out, and actually works really well.
[ed: as per my other comment, see also eg:
Their documentation is great, though, so it's a good place to start: http://docs.racket-lang.org/
SICP - http://mitpress.mit.edu/sicp/
HTDP - http://htdp.org/
Dan Grossman's Programming Languages Coursera course - https://www.coursera.org/course/proglang
The Racket docs - http://docs.racket-lang.org/
Chris Jester-Young's StackOverflow answers - http://stackoverflow.com/search?q=user:13+[racket]
This list won't be as useful to you as it was to me, because you already know Common Lisp, but hopefully other readers will find it interesting.
NB - the ProgLang Coursera course features Racket alongside SML, Ruby and quite a lot of material that will seem very basic to experienced programmers, but it's a really good introduction of some of its key features. I think this is probably my weakest recommendation to someone who already knows Common Lisp (or similar) and my strongest recommendation to someone who does not.
Beyond that, the default DrRacket IDE comes with a whole load of teaching resources bundled by default, including (iirc) resources to help build a game in Racket - this package I think http://docs.racket-lang.org/teachpack/2htdpuniverse.html.
As for differences/advantages of Racket, I would say that there are few that I'm aware of beyond the simplicity of learning the language, the great tools, and the ease with which you can get up and running. Nothing inherent to the language that I'm aware of, and I would suspect that Common Lisp is great if you're already part of that community and 'know where everything is' so-to-speak. I've heard that CLOS is better than Racket's OOP abilities.
I really do love the language, though, it's one of the easiest and most joyful experiences I've ever had with a programming language. Just maybe not a necessity if you already know CL.
Their pattern matching is easier to extend than optima though.
You could work through SICP using Racket instead of MIT/GNU Scheme. I'm currently in the midst of this and the differences thus far have been relatively minor (e.g. Racket doesn't have `inc`, `dec` or `nil`).
I'm assuming those are trivial to add?
inc and dec I assume mean increment or decrement (I have no experience with CL) - racket/base includes (add1 .) and (sub1 .) for the same effect. If they didn't exist they would be trivial to add I think - if this isn't what inc and dec mean then I apologise.
In Scheme/Racket truth and falsity is really simple - #f is false and everything else is truthy. There's also already a null value for the empty list (which is 'true'). I don't know if nil would be useful.
In Common Lisp, unlike Scheme/Racket, nil is the null value AND the false value. In Scheme/Racket, 'nil is true unless you define it to be #f. If you wrote an if or cond expression to evaluate the 'nil in the link, I think that it would return true, whereas in CL nil is falsy (I think it is the only falsy value in CL, but I would still describe it as 'falsy' rather than false, possibly incorrectly).
e: Ah, I see why I'm not understanding you now - you're talking about the differences between Racket and SICP/Scheme whereas I made the assumption that we were talking about the difference between Common Lisp and Racket (from OP's comment). To further clarify, I believe this was my fault in comprehension, not yours in communication.
But it is how nil is defined in SICP:
'The value of nil, used to terminate the chain of pairs, can be thought of as a sequence of no elements, the empty list. The word nil is a contraction of the Latin word nihil, which means "nothing."' -- http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html...
And then in a footnote to that paragraph:
"It's remarkable how much energy in the standardization of Lisp dialects has been dissipated in arguments that are literally over nothing: Should nil be an ordinary name? Should the value of nil be a symbol? Should it be a list? Should it be a pair? In Scheme, nil is an ordinary name, which we use in this section as a variable whose value is the end-of-list marker (just as true is an ordinary variable that has a true value). Other dialects of Lisp, including Common Lisp, treat nil as a special symbol. The authors of this book, who have endured too many language standardization brawls, would like to avoid the entire issue. Once we have introduced quotation in section 2.3, we will denote the empty list as '() and dispense with the variable nil entirely." -- http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html...
Apologies for the confusion.
In that case, I don't think it's possible to define an exact equivalent of CL's nil in Scheme, as nil means both false and the empty list in CL -- the latter being falsy in CL and, as you point out, truthy in Scheme.