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."
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.
I'm with you on the recommendation of learning Erlang, but not for the same reason you are. The vast majority of new systems are at least dual core today. Most people run at least two programs, often meaning that one program can run entirely on one core, and another program runs on another core. Intel recently announced quad-core CPUs, and the first prototypes have got into a few people's hands. It looks like as time goes on, instead of upping the clock speed, the number of cores will increase. Most programming languages in use today, make it hard to do concurrency (or at best, don't make it easy), but Erlang was designed as a concurrent language from the get-go. I am inclined to say that the next generation of effective languages will be similar to Erlang, in their ability to support concurrency, and that programmers who don't get used to writing in some form of concurrent languages will be left behind.
Sigs are like bumper stickers.
Actually, Scheme/LISP was designed for "correctness" rather than for ease of compiler implementation. Take for instance something like
x = y + 1;
in C. That doesn't actually mean "x = y + 1" it means "x = y + 1 (mod 2^32)". Why is it done this way? Because it is a lot easier for a compiler designer to implement integers if they are always a fixed number of bits.
On the other hand, Scheme does it the correct way, so that (set! x (+ y 1)) actually does what it looks like it does. This is one of the reasons C compilers took off in the 70s while lisp compilers stagnated. I suggest you read the paper "Worse is Better"
---
Your resident MIT student
PS. Don't take this as support for Scheme. I hate Scheme.
As for what "Scheme is defined by", it doesn't matter: You program with implementations, not standards
We're not discussing whether Scheme is a good language to program in (that's a separate debate), we're discussing whether it's a good language to communicate ideas in, as the GP claimed.
Furthermore, Scheme, as it is now, can be a very good "grown-up" language (whatever that means).
It means that programmers and computer scientists find other languages more useful for communicating their ideas and getting their work done.
See Chicken Scheme and its large number of bindings for networking, graphics, sound, et cetera.
Implementations of Scheme with excellent bindings have existed for two decades, yet one new language after another has overtaken Scheme: Perl, Python, Tcl, Java, Ruby, C#, PHP, the list goes on. Evidently, people really don't want to use Scheme.
Isn't a central point of Scheme that it is properly tail-recursive, functional programming language? While I'm not all that familiar with Scheme, wouldn't you usually use a recursive function rather than a for-loop in such a language?
A for-loop isn't a task, its a construct that is natural in the idiom of certain languages for accomplishing certain tasks. Its not the idiomatic way to approach those tasks in all languages, though.
Most modern C compilers will do tail-call optimization. However, it is not a requirement of the language (an implementation that fails to do so will still be "C"), and so implementation-agnostic portable code shouldn't count on it, and the language itself provides strong support for programming constructs that make sense when you can't count on tail-call optimization.
Functional programming languages that require tail-call optimization as part of their definition, tend not to support such constructs as well (or, when they do, to do so as syntactic sugar for a recursive implementation), but rather use recursive functional idioms to address the same situation. These may be less natural appearing if you've spent lots of time working with imperative languages where those approaches aren't the natural solution (and where likely you've had "don't use recursion unnecessarily" beaten into your head), but recursive expressions of algorithms tend to be both compact and clear.