Slashdot Mirror
Draft Scheme Standard R6RS Released
Watson Ladd writes, "The new version of the official Scheme standard has been released as a draft (PDF)." From the draft: "[This] report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and message passing styles, find convenient expression in Scheme."
(I (for one (welcome (our new (Scheme (overlords.))))))
Scheme is a language that every programming language enthusiast should know. Being both simple and flexible, it's suitable for communicating and explaining all kinds of concepts. A lot of books and papers are about Scheme or use Scheme for examples or teaching (see Readscheme.org). Scheme also pioneered some of the concepts in modern programming languages (such as lexical scoping), as well as several uncommon features (such as hygienic macros and first-class continuations). There are many Scheme implementations, some tiny, some slow, some fast, some with extensive libraries, some which interface to other programming languages, etc. etc.
Please correct me if I got my facts wrong.
The GNU project adopted Scheme (with the Guile interpreter) as its official scripting language. Applications are not meant to be written in Scheme, but applications can expose functionality to the user through a Scheme interface. That is to say, plugins for extensible applications could be written in Scheme. The Gimp is one of the most noteworthy applications with a Scheme interface, and much of the lower-level functionality of GNU Lilypond is reached with Scheme.
I've never heard about this language, but hopefully the new version will help it keep up with the latest innovations in programming languages, such as codeblocks and Web 2.0.
Yours truly,
Fictional stereotypical teenage Ruby fanatic.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
For those of you who don't know what "properly tail recursive" means, a quick explanation. Consider the following code:
:-)
(define (f x) (x x))
(f f)
This defines a function, f, which takes one argument, x, which should be a function (yay, first-class functions!), and calls x upon itself. Then, it calls f on f.
Of course, this will cause f to call f upon itself. Again. And again. Infinite recursion!
Now, proper tail recursion means that if a function call returns in tail position (meaning it is the last thing the surrounding function does before it returns), the activation frame for the surrounding function is replaced by that of the function it calls. Contrast this with normal recursion, where a _new_ activation frame would be created for the called function.
Tail recursion makes the example code above run in bounded memory...looping forever.
Please correct me if I got my facts wrong.
But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.
Lisp syntax certainly does not attempt to look like the combination of English text and mathematical formulas that most languages shoot for, but this in fact has many advantages. The idea of making a language look like that doesn't change the fact that the language will work in a way very different from English or mathematical notation; your previous knowledge of those things will not necessarily help you reason about your code, and at worst, may confuse newcomers by tempting them to apply analogies that don't hold. And to achieve that "look" for your language, you always end up giving it a really complex and inflexible syntax, whose users are not going to have any systematic knowledge of. (Do you know many people who can give you a BNF grammar for Java, or tell you the exact precedence rules for it?)
Lisp makes no pretence at looking like English or mathematics. You're certainly expected to understand the syntax rules of the language more than in "friendlier" ones, but these rules are far, far simpler, and you can actually reason them through. Remember, Scheme oooks regularly include a section that shows you how to write a Scheme interpreter in one page of Scheme code; basic knowledge of how Scheme itself works is considered to be elementary Scheme knowledge.
That is, what I'm saying is that compared to other languages, Lisp dialects demand that you understand the language itself far more, but this is a good thing, which will make you program way better. Why? Because you're going to be able to reason about the execution of your program far better than your average Java programmer.
Plus, you can do macros.
Are you adequate?
This is only distributing until you remember that almost every implementation has to implement something similar, often in a way that's slightly different and incompatible with everything else. I'll agree that there is a danger, yes.
However, I personally feel that R6RS is nearly at the perfect point. It is still very heavily leaning towards simplicity and clarity, but includes the bits that everyone ends up implementing anyway in non-standard ways. The truth is that modern unix systems are ugly, i/o is complicated, and a lack of a standard macro system (see the syntax-case variants) is horribly annoying. R6RS does reflect all of this, but I think trying to cleanly negate issues is far better than simply ignoring them. There are a few things that I think overreach, but I'm very happy with 95% of the additions. This is a standard we can make use of for the next 10-20 years.
but its really not the lanuage that you would want to use for your daily work, for that it simply lacks a lot of convenience features (++a becomes (set! a (+ a 1))
This just shows a lack of fundamental understanding of how one typically writes Scheme programs. If you're incrementing variables to the point where that becomes a concern, you're completely misusing the language.
even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.
Again, this shows you have no experience with the language, or you've been using it horribly wrong. There's no reason you should ever need a for loop in Scheme. If you're going to use Scheme as mostly imperative language, you're better off with Python or similar.
This always comes up, but if you're at all interested in programming languages, here's why you should learn Scheme.
A few years ago I was doing a project that involved parsing the intermediate code that GCC generated while compiling a C program. Doing a bit of research I found out that one of GCC's intermediate stages was a language called RTL (register transfer language). To my surprise, RTL looked something like this:
(set (reg:0) (mem:blah blah))
But wait, I thought -- that looks like Lisp. Come to find out RTL was based on lisp s-expressions.
It was then I realized what the Big Deal with Lisp was - it has no syntax at all, and programs written in this parenthetical form are trivially converted into a parse tree. In fact, if you've ever written a simple interpreter or compiler, odds are good you'd use a list-like structure to store the parsed code.
The reason Lisp and Scheme are so "powerful" is that you, as a programmer, have direct access to the program's parse tree at all times. (You can even alter the parse tree at compile time with macros, which is really modifying the compiler to suit your program.)
But really, the best way to learn why Scheme or Lisp are so great is to implement them. Writing a Scheme to assembly compiler will give you an incredibly deep understanding as to how compilers and programming languages in general work.
If you were to try to write a compiler for any other language, you'd probably spend most of your time on the lexer and parser. With Lisp or Scheme, the program, as written, is already almost fully parsed for you. Once you understand that, you'll realize why it's so cool.
If moderation could change anything, it would be illegal.
I am sure there are a numer of ways to learn Scheme if you are interested. Here's one: follow the CS-61A course podcast of Brian Harvey's class at Berkeley.
meh.
``"properly tail recursive" is an oxymoron. Tail recursion is not proper. Decent programmers use loop constructs for looping.''
That's highly debatable. I would agree that when you want to express the concept of a loop, it's best to use a looping construct, but other people would disagree. Also, tail calls are more general than loops; for example, they also work for mutually recursive functions.
Which is more elegant?
int gcd(int a, int b) {
return (b == 0) ? a : gcd(b, a % b);
}
or
int gcd(int a, int b) {
int t;
while (b != 0) {
t = b;
b = a % b;
a = t;
}
return a;
}
``Your problem is that Scheme can't do that.''
That depends on what you mean by "Scheme can't do that". It's entirely possible to implement looping constructs in Scheme, and several people have done so. Scheme can't do looping in the same sense that C can't compute factorials.
``When all you have is a hammer, everything looks like a nail.''
Except that, in Scheme, you can make your own tools on a much more fundamental level than in many other languages. Thanks to tail call optimization, you can _implement_ looping constructs, even though the language doesn't provide them.
``Needless recursion makes your code more convoluted and less readable.''
I think the example I gave earlier illustrates that, sometimes, recursion leads to less convoluted, more readable programs. The right tool for the job, ey? In a language that isn't properly tail recursive, the recursive gcd would be a bad idea because the recursion would eat memory, but in Scheme it's no problem.
``It's amazing how people can claim a deficiency as some kind of advantage. You just keep smoking...''
I'm not claiming a deficiency as an advantage. I'm claiming tail call optimization is a nice features to have. There is no deficiency here.
You could argue that the lack of looping constructs is a deficiency. However, the lack of looping constructs (1) is not at all implied by the language being properly tail recursive, (2) is easily remedied, and (3) actually has been remedied in many implementations.
And no, I don't smoke, though I do live in the Netherlands.
Please correct me if I got my facts wrong.