[racket] variables within macros

On Jan 18, 2013, at 3:22 PM, Rüdiger Asche wrote:

> Scheme used to be plainly beautiful. Understand lambda expressions, recursion and continuations, and everything else more or less falls into place.


Rüdiger, 

let me take exception to your message in the sense of your email and in the sense of the above sentence. 

While both Laurent and Greg have basically hit the nail on the head in their responses, I would like to tell this story a bit more explicitly. When I was young and innocent, I thought Scheme was all I needed. I could write interpreters, more interpreters, and yet more interpreters. Hey, I could model an operating system, and another operating system, and yet another one. BUT, the word 'model' is the key. Nothing was real. It was all wonderful toy programming and toy mathematics. 

In Jan 1995, I launched the effort that you're looking at right now. I still thought I wanted Scheme and I told everyone around -- especially Matthew -- that I wanted it. On one hand, we really wished to build this educational effort. On the other hand, we also wanted to show how great Scheme was as the implementation language. If we needed to explain our work as research, this second 'hand' was definitely our key. 

Scheme failed us. 

If you wish to manage a large code base that sports portable graphics, supports a decent graphical IDE, and helps you teach introductory programming smoothly, you cannot get away with plain Scheme -- certainly not the one we had in 1995 and not in any small Scheme that the wise men on the R7RS committee will come up with. There are three problems with this small-is-beautiful Scheme: 

 -- you need the same abstractions over and over again: this calls for a library system with proper linguistic support. Contrary to rumors, you can't really build this support from lambdas and S-expression macros. Is our syntax system perfect? Far from it, but it is better at just this task than anything else I have encountered. So this is how we currently have #' #` and #,. 

 -- you need to build teaching languages, because Scheme -- like all other off-the-rack languages -- are inappropriate for novice students. In particular, you must be able to subtract constructs from a language, shadow properly, and protect. You can't do this in Scheme. This is where the syntax system got launched. 

 -- you need certain abstractions that are plain not expressible in Scheme. I mean this in the sense of my notion of expressiveness NOT in the sense of CHURCH-TURING computability. Examples: real threads, resource management (otherwise students can't even stop run-away programs -- in Scheme); GUI event management and separation of event spaces for student programs and systems programs (otherwise students can't be protected from their own GUI event handlers -- in Scheme); and as you scale up the IDE so that it works for more experienced programmers, you need more. 

See revenge of the son of the lisp machine for technical details. 

Next, Scheme failed us in staying competitive. 

As time went on, Lisp-wanna-bes came about in all shapes and forms: Perl, Python, Ruby, JavaScript. They all have good things to say. Like these, we wanted to use our language to get our daily and monthly chores done (write NSF proposals, grade, look up checking accounts, assess stock quotes, do our taxes, you name it). And these guys knew how to get these chores done in a convenient way. Not Scheme. 

Let me describe one example. I was writing an NSF proposal that involved another Schemer. I needed a script to submit the bibliography separately from the proposal body (a then-new requirement). I wrote a five liner in PLT Scheme now Racket and I was done. The colleague translated this into "standard" Scheme. A page and a bit later he was kind of done with his script. It included a crude approximation of our regexp library and our port regexp reader and some more. Sure enough it was portable, but I had used this time to write half the proposal. 

So yes, we have #hash tables and sets and many forms of data and for/foo*bar loops and many other conveniences. But without them "Scheme" is not even behind in the race to get things done. It simply doesn't exist. 

I do not mean to demean Scheme. It got me started. It is still the core of our ideascape. It is a wonderful piece in my personal museum of programming language knowledge. What I wish to reject is the idea that "some small Scheme is all we need" - an idea that crops again and again and again and despite all of its staying power, it is all wrong. 


-- Matthias