Emacs: Racket on Windows

As a continuation from my last post, I also want to show how to install Racket on Emacs for Windows.

I'm going to show the easiest way (that I know of).  So, this will not install the most recent version of Emacs, but will be the quickest and easiest way possible.

In order to install Emacs, I'm going to use Chocolatey.  Chocolatey is the budding Windows package manager based on NuGet.

So here we go!

Chocolatey (Powershell Install):
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Emacs (super text editor):
cinst emacs

Geiser (Racket support for emacs):

• Find your .emacs file
• Open emacs and find .emacs file by using:
• C-x C-f ~/.emacs  (~/ is the current home directory)
• Add package archive configuration to .emacs
• Add this to the .emacs file:
  (require 'package)
  (add-to-list 'package-archives
    '("marmalade" . "http://marmalade-repo.org/packages/"))
  ;; You don't need this one if you prefer marmalade and released versions:
  ;; (add-to-list 'package-archives
  ;;  '("melpa" . "http://melpa.milkbox.net/packages/"))
  (package-initialize)
• Install the package
• Open emacs
• M-x package-install RET geiser RET (RET is press <enter>)

You should now be able to run Racket mode by opening emacs and doing the following:

M-x run-geiser

> Start Geiser for scheme implementation: racket

This should start the REPL.

Emacs: Racket on Ubuntu

Well, I'm finally digging into Emacs as a text editor for Lisp and Erlang.  I've picked up Learning GNU Emacs which I'm enjoying.  During my study with SICP, I'm using the Racket flavor of Scheme. 

One of the issues so far, though, has been how to be install and use Emacs with Racket on Ubuntu.  So, I don't forget I'm going to record what configuration I ended up using.

Emacs (extra-super text editor):

sudo apt-get install emacs

Geiser (Racket Scheme support for Emacs):

sudo apt-get install geiser

Quack (enhanced Scheme mode for Emacs):

sudo apt-get install emacs-goodies-el

After installing the tools above.  I open terminal session and type emacs -nw to open Emacs.

Once Emacs is open, in order to enter Racket mode, I use Geiser by running the following commands:

M-x run-geiser RET racket RET*

*RET - hit enter

At this point, you can open up a Racket REPL, by running:

C-c C-z

This will open up another buffer and start a Racket REPL in the window.

I tend to like to be editing a Racket file and then, when I'm ready load the file into the REPL for testing.  To do this, save a file:

C-x C-s  (then give a file name, ex. test.cl)

Add some Scheme definitions to the file and then save using the same command.  Then, when I'm ready to test run the following:

C-c C-a

This Geiser command will open a REPL and then load the current file into the REPL session.  This allows you to switch back and forth between the REPL buffer and the file buffer.  So far, I'm finding this to be the best configuration.

SICP Insight

Recently, I've joined the Structre and Interpretation of Computer Programs (SICP) London meetup.  The meetup is run as a coding dojo switching pairs for each problem from the SICP book.  To support study of this book, there are some great lectures on the MIT Open Courseware website.

Keeping in mind these lectures were arranged for Hewlett-Packard in 1986, this section stood out.  By the way, these comments by Hal Abelson are during a discussion about creating a data abstraction for rational numbers (and don't worry about who George is).  The full transcript is available with the MIT course.

But the real issue is that you might not be able to decide at the moment you're worrying about these rational numbers. See, in general, as systems designers, you're forced with the necessity to make decisions about how you're going to do things, and in general, the way you'd like to retain flexibility is to never make up your mind about anything until you're forced to do it. 

The problem is, there's a very, very narrow line between deferring decisions and outright procrastination. So you'd like to make progress, but also at the same time, never be bound by the consequences of your decisions. Data abstraction's one way of doing this. What we did is we used wishful thinking. See, we gave a name to the decision. We said, make-RAT, numerator, and denominator will stand for however it's going to be done, and however it's going to be done is George's problem. 

But really, what that was doing is giving a name to the decision of how we're going to do it, and then continuing as if we made the decision. And then eventually, when we really wanted it to work, coming back and facing what we really had to do. And in fact, we'll see a couple times from now that you may never have to choose any particular representation, ever, ever. Anyway, that's a very powerful design technique. It's the key to the reason people use data abstraction. And we're going to see that idea again and again. Let's stop for questions. 

AUDIENCE: What does this decision making through abstraction layers do to the axiom of do all your design before any of your code? 

PROFESSOR: Well, that's someone's axiom, and I bet that's the axiom of someone who hasn't implemented very large computer systems very much. I said that computer science is a lot like magic, and it's sort of good that it's like magic. There's a bad part of computer science that's a lot like religion. And in general, I think people who really believe that you design everything before you implement it basically are people who haven't designed very many things. 

The real power is that you can pretend that you've made the decision and then later on figure out which one is right, which decision you ought to have made. And when you can do that, you have the best of both worlds.

This is such a clear explanation for so many parts of good software design.  In a couple of minutes, Prof. Abelson goes to the heart of modular design, abstraction layers, deferring design decisions, and iterative development practice.  Just goes to show that the proper way to do this hasn't changed in a while (even though it sometimes is packaged differently).