Sanity Check

Bad idea?
(defmacro letret (return-binding bindings &body body)
  `(let ,(cons return-binding bindings)
     ,@body
     ,(first return-binding)))

(defmacro letret* (return-binding bindings &body body)
  `(let* ,(cons return-binding bindings)
     ,@body
     ,(first return-binding)))

Just get plt scheme, >>9. Chances are good you'll do what everyone else does, be amazed, have the odd epiphany or three, and then program in some other language anyway.

>>9
When it comes to ANSI Common Lisp, there's a few choices for your platform(Win32):
a) `Free' ones(come with source code):
 - SBCL,
    pros: very fast/good code quality, good extensions, based   on  CMUCL, but made to be much more portable. Most of the Lisp community prefers it
    cons: threading support is lacking on windows, but it's being worked on, same goes with interrupt support. I find it usable, but YMMV. These issues don't exist in the *nix port.
 - ClozureCL/OpenMCL, used to be a commercial lisp, now open source.
    pros: almost everything works if you use the latest SVN trunk.
    cons: not as good native code generation as SBCL, but still decent.
 - CLISP
    pros: good compatibility, good for debugging
    cons: Interpreted or JIT when compiled, no threading.

Commercial(have to pony up money or get a free trial):
 - Allegro CL
    pros: good code generation, lots of libraries come with it.
    cons: , and the license is  restrictive, but they can give you source code to parts of the implementation, has a free trial.
 - Lispworks
    pros: good debugger/code stepper, various interesting libraries, better license than ACL
    cons: haven't used it enough to know any
 - CormanCL
    pros: Good concurrency support, get full source code if you buy it.
    cons: Win32 only, are they even alive anymore?

All have excellent ANSI Common Lisp support, so your code is portable. FFI, Networking, Concurrency(SMP) are not standardized features, so things vary here, but for FFI and Networking you have compatibility layers which allow you to write de-facto portable code across any of these implementations ( when you use Emacs+SLIME, you can even run multiple ones at the same time, or you could even run an implementation in a VM or a remote machine and connect them via network seamlessly ). Code generation quality(speed/bloat/etc) varies as well. I'd say go with latest SBCL or SVN trunk CCL, they should be good enough for your needs. If you don't care about speed or concurrency just use CLISP. Pretty much all of them have an FFI, and you can use CFFI or UFFI as a compatibility layer if you want a portable FFI. Basically, you can't really go wrong, and if something doesn't suit you, you can just easily switch implementations, unless you wrote some very implementation specific code.

>>11
As for tools, you'll want Emacs+SLIME+Paredit, check this movie out to get started: http://common-lisp.net/project/movies/movies/slime.mov

hOLY SHIT YOU FUCKING FAGGOTS STILL TALK ABOUT "LEARNING LISP". wHY DON'T YOU ACTUALLY START READING A FUCKING BOOK YOU PHOOKKIN PHAGH?

>>11
I prefer GNU Guile.
No R6RS support but I like their module system more than the standardized one.

>>14
http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Using-Guile-Modules.html#Using-Guile-Modules

Is there some Scheme or Lisp that generates TINY executables?

>>16
No, because compiled versions are just a sticked-together version of the actual script and the interpreter itself.
Which is why most free interpreters use the LGPL.

>>17
I don't know about Schemes well, but this is incorrect for most modern Common Lisp implementations. Those that compile down to native code will get you clean nice functions, however they're not linked inside a normal executable, instead you can have code and data in the same [b]core image[/i], that is, similar to how normal executables look, but a bit more chaotic (this image can and is gc'ed usually), then you have a tiny executable which just loads the image in memory and runs the entrypoint, as well as provides a few services such as gc. That's how most serious Lisps work, and this is a fine model as the core image is very modifable (you can define and redefine just about anything in this image), Lisp's dynamic nature does not stop at just dynamic typing: the entire environment can be modified and extended at will. There are some interpreted Lisps, but I can only think of CLISP(which can compile to bytecode(JITable), so it's not a pure interpreter) and Lisps of old days. If this does not suit your needs, you may want to look at Lisps which compile to C code, and you can compile those as a normal executable(~1-2MB runtime most of the time), such an example would be ECL(Embeddable Common Lisp), but it surely isn't the only one. CL is large, but if you truly want tiny images, then select a subset of CL and treeshake your world, or use one of those tiny embedabble schemes. There's also Gambit-C for Scheme (compiles to C). Other ways to obtain small images involves tree shaking the image(removing symbols(and dependencies of them) which are not needed by you and gc'ing).

tl;dr: Most images are large, but you can get them small if you need them. They're large because they provide a lot of things(Most normal languages don't come with an entire compiler inside them).

>>17
Actually the LGPL isn't very suitable for a lot of CL implementations, which is why most are public domain or BSD or LLGPL. The thing about it is that the code gets linked into the main image, dynamic linking is uncommon (it can and is done in some cases, but as my previous post showed, most of the cases involve a form of static linking(for the lack of a better term)), so you need a special linking exception to the LGPL if you want to use it. Most free Lisp libraries end up being BSD/Public Domain or LLGPL. There's a few LGPL'ed ones, but that's mostly because originally the authors weren't aware of this issue, and it's too hard to contact everyone to change the license. Commercial Lisps also have special linking exceptions in their licenses (runtime licenses).

>>11
Tried Lispworks before. The interface is claustrophobic :(

>>20
It's probably fine if you want an IDE, but a bit minimalistic. It does work with SLIME like pretty much any other major Lisp implementation, so it shouldn't matter much.

>>21
Jaysus, it's got at least 20 miniature buttons (ten in a window, ten floating around in a toolbar) without descriptions I don't understand. I've switched to ABLE for a while but it's no DrScheme.