Slashdot Log In
Draft Scheme Standard R6RS Released
Posted by
kdawson
on Sun Sep 17, 2006 02:21 PM
from the scheming-with-a-lisp dept.
from the scheming-with-a-lisp dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Hurray! (Score:5, Funny)
Re: (Score:3, Funny)
(welcome '(I ((for one))) '(overlords (our new Scheme)))
?
Re: (Score:3)
Re: (Score:2, Informative)
Thith ith awethome (Score:2)
Re: (Score:2)
Re: (Score:2)
For Language Enthusiasts (Score:5, Informative)
Re:For Language Enthusiasts (Score:4, Informative)
No, it (or some other Lisp dialect) is a language that every programmer should know. Every programmer should know Lisp, Smalltalk, and either C or some dialect of assembly language (ideally both). As a bonus, they should also know Haskell and Prolog. Once you know these languages, it is trivial to pick up any other. I would also recommend Erlang; not because it's a particularly good example of anything, but just because it's a real joy to work with.
Parent
Re: (Score:3, Interesting)
ML vs Haskell (Score:2)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Re: (Score:2)
Scheme is an extremely cumbersome language for experienced computer scientists to communicate ideas: Scheme lacks many concepts (e.g., exceptions, threads, records, associative data structures) that are widely used for communicating ideas. That may be justifiable for a teaching language, but it makes Scheme too cumbersome for most other purposes.
Scheme also pioneered some of the concepts in modern programmi
Re: (Score:3, Insightful)
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 the
Veni, Vidi, Parenthesi (Score:2)
New features? (Score:5, Funny)
Yours truly,
Fictional stereotypical teenage Ruby fanatic.
Scheme and Common Lisp... (Score:3, Informative)
It's just such a pity that, since they're both standards which anyone can implement, lots of people do, and as a result, finding one you like and then getting it to talk to other languages and libraries can be a very frustrating experience. And languages like Python with one canonical implementation driven by a BDFL and with exceptional library support are just getting more Lisp-like, which can't be good news for for a renaissance in Lisp or Scheme. Pity really, since I really like 'em both...
Tail Recursion (Score:5, Informative)
(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.
Re: (Score:2)
Re: (Score:2)
Re:an oxymoron (Score:5, Interesting)
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.
Parent
no it doesn't (Score:3, Interesting)
gcd:
cmpwi 0,4,0
bne 0,.L7
blr
Re: (Score:3, Insightful)
Functional programming languages that require tail-call optimization as part of their definition, tend not to support such constructs as well
So what's new? (Score:2)
Which isn't surprising. r6rs is twice as long as r5rs which had the entire table of contents on the first page.
I'm glad to see that a lot of the slib stuff is being merged into scheme, and that they're making a lot of progress on number types. r6rs is laying out a lot more information on ADTs, IO and Unicode support.
The explanation of continuations is still as clear as mud. How are they so easy in Python and so hard in Scheme?
Continuation Crash Course (Score:3, Interesting)
A continuation is "the part of the program that hasn't been executed yet". If your code is
(foo)
(bar)
(baz)
and you've just executed (foo), the continuation is (bar) (baz).
In Scheme, continuations are first-class values, which means they can be stored in variables, returned from functions, passed as arguments, etc.
There is a single way to create continuations, namely through the call-with-current-continuation form (often abbreviated call/cc). You pass call/cc a fun
Why should I learn Scheme? (Score:5, Interesting)
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.
Learn Scheme (Score:4, Informative)
Re:Learn Scheme (Score:5, Informative)
Parent
Re:Qs (Score:5, Informative)
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Scheme's first-class continuations [wikipedia.org] are actually a very good match for web programming, where a user can re-submit an old form at any time. Basically, with languages that lack call/cc, you will have to break up your application in little pieces to account for this, whereas call/cc allows you to structure your application like a regular one, and the language implementation will deal with the issues.
When it comes to practicality, it all depends on the implementation. The Scheme
Re: (Score:2)
True, but that's neither here nor there. A language can make an excellent text processing, web programming, scripting, etc. language without needing extensive libraries.
Re: (Score:3, Interesting)
I won't argue this point further. I've already stated that languages without _extensive_ libraries can still be useful in specific domains. I still stand by that view.
``And languages like Scheme and Lisp are particularly crippled because they don't even have a standard extension mechanism.''
Huh? The package system is a standard feature of Common Lisp. R6RS may standardize a module system for Scheme (although this is not certain yet);
Re: (Score:2)
No, no, no, no, no, no and no.
Re: (Score:2)
Short subjective answer: No
Scheme is a nice language and has some very interesting properties, so learning it is well worth it, 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)) and it also lacks standardization bejoint its very core, which means that every Scheme implementation comes with its own set of libraries for all
Um. (Score:2, Informative)
;;; Macro to increment a variable by one.
;;;
;;; Usage:
;;;
;;; (define a 5)
;;; (inc! a) ; a is now 6
;;;
(define-syntax inc!
(syntax-rules ()
((inc! x)
(set! x (+ x 1)))))
Not that idiomatic Scheme code will do this very often. Langauges like Java or C use "++a" most often for loop indexes. Looping in Scheme is typically driven off data structures.
Re:Qs (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
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 i
Re: (Score:2)
You're joking, of course. It's a language specification.
If you insist on having a condensed version, it would read:
Re: (Score:2)
Re: (Score:2)
very disturbing, writing unix-style script execution syntax into
the language. its clear that they are going for pragmatism and adoption
rather than the clarity that was present in the earlier definition.
frankly really i wish they had just stuck to core+sfri (and left
hygenic macros as an sfri)
Re:142 page PDF... (Score:4, Insightful)
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.
Parent
Re: (Score:3, Interesting)
Description of differences here (Score:3, Informative)
Since Scheme wasn't the one of the versions of LISP that I learned back in the dark ages, I couldn't really follow the subtleties of which changes are really significant, but it looks like it would make sense if you were following Scheme.
Re: (Score:2)
Re: (Score:2)
(display "> ")
(write (eval (read)))
(newline)
(loop))
Re: (Score:2)
Lisp syntax has great cognitive advantages (Score:5, Insightful)
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.
Parent