リスプ－１。

Whats your favorite Scheme standard nowadays, /prog/? Are you coding from a standard or implementation specific?

        1975 "Scheme: an interpreter for extended lambda calculus"
3 yrs   1978 RRS
     << 1984 SICP >>
7 yrs   1985 RRRS
1 yr    1986 R3RS
5 yrs   1991 R4RS
     << 1996 SICP 2nd E >>
7 yrs   1998 R5RS
     << 2001 HtDP >>
9 yrs   2007 R6RS
5 yrs   2012 R7RS-SmL-draft6

Racket.

The first two ones were fresh, while unpolished. I guess it took some time for things to settle and for lambda to become ultimate. R²RS was very cool. There were focus and neatness but there still was a hint of a playful and free Rabbit. In the following decade and a half things got more formal and academic, but our favourite language was at nonetheless beautiful and light. Close to perfection.

But then some people in the steering committee got envious of Java (or was it Python?) and it got all ENTERPRISEy. Why would you do that? You threated her like a whore!

R5RS and earlier are the best. R6RS goes against the Scheme philosophy. The mandated IEEE floats and UTF-32 characters decrease portability. Portable languages should be sufficiently general and abstract to be implemented 100 years from now, like C89 is. Tying it down to specific binary representations is harmful. R7RS will be even worse once they replace continuations with more limited exceptions.
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

I had hopes for R7RS, but they're too concerned with backwards compatibility to fix the mistakes R5RS made/inherited from R4RS and the IEEE standard. My hopes for R7RS died when they decided to stay with SRFI-1 records, and left after the unspecified value vs values argument.
With the right abstractions, backwards compatibility could be achieved anyway, but NO!, we must continue to get things wrong.

So, Racket.

>>4
mandated IEEE floats
That's actually a very good thing.

>>5
Could you elaborate on what mistakes of R5RS you mean? And what kinds of records would you prefer?

Personally I wanted to see a good pattern matching library instead of records to be default. What's with records, really? They don't look good in LISP.

>>6
IEEE-754 floats cannot store an exact representation of many commonly used non-terminating decimal numbers, even 0.1. If floats were implementation-dependent, the implementation could use decimal floats such as IEEE-754r which can store numbers like 0.1 exactly.

>>7
Could you elaborate on what mistakes of R5RS you mean? And what kinds of records would you prefer?
* Lack of modules. Not really a mistake, there's still no One True Module System today, I doubt there was one in 1998.

* syntax-rules is perfect for trivial things, but it doesn't scale up well when things get complex. Again, not R5RS' fault, good, powerful and sane hygienic macros are a recent thing (And by that, I mean syntax-parse)

* set! & co. returning an unspecified value.
This is why all Schemes need a special #<void>/#<unspecified> value. The spec should really say they return unspecified values, such that they can also return 0 values, which is the sane thing to do.
This is actually a mistake inherited from R4RS, which had no multiple values, so it needed the ``unspecified'' value. R5RS introduced multiple values, but didn't lift this restriction.
Of course, set! can just return the previous/new value of the set!ed variable, but there's not meaningful return value for when, display, for-each, etc.
Why do I care so much about this? Because it's a pointless and stupid restriction.

* call/cc over control0+prompt. Not R5RS fault.

* Lack of user-defined data structures.
R7RS had a good proposal^{_{here it is: http://trac.sacrideo.us/wg/wiki/RecordsGleckler}} for a forward-compatible (i.e., extensible without breaking code) syntactical records system, backed by a procedural interface, like R6RS records without the bloat.
I personally prefer ADTs over records, but I can't imagine using them in a Lisp.

>>9
Generic methods with multiple dispatch actually make adts very nice in lisp. It certainly feels a lot different when typing the stuff out, but the programming isn't any different from using oo in some other dynamically typed language, where you find out the object doesn't have an implementation for the method you are calling until runtime.

control and prompt look very interesting. I've read another paper also by Felleisen where he described another alternative of his: continuation-graft. He must really dislike call/cc, and I must say that I can't be too apologetic of it.

But I've always wondered about the need for user-defined types and data structures. Can't you build everything out of lists (and other primitive aggregate types)? Why is it better to dispatch on type than on structure with match and match-lambda? Let badly formed data fail (early). What about racket's contracts?

Information hiding and encapsulation in plain data is useful when your operations on them are destructive. But with mostly immutable data structures it's not nearly as important.

>>10
Something like
(define-datatype list
 (cons car cdr)
 (nil))
?
It doesn't feel much different than (define-record cons (car cdr)), (define-record nil ()), or maybe I'm just retarded and can't figure out Lisp-friendly ADTs on my own. Care to give me an example of what you mean?

>>11
call/cc isn't really worth the pain, delconts are simpler to implement, easier to use, and can be less memory-intensive and faster.
Can't you build everything out of lists (and other primitive aggregate types)?
That's how you implement records on top of R5RS, using vectors. But, sometimes, you really want records to not be vector?s, and redefining vector-* feels wrong IMO.

>>12
>But, sometimes, you really want records to not be vector?s
Right, I think I understand you point. So if you dispatch on type, it's bad if vector? evaulates to #t for both #(1 2 3) and the ``record'' #(person "John" 42). One solution is to never treat vectors and tagged-records-made-of-vectors at the same level. But that might not be feasible.

However, if lists and vectors could be operated on with the same procedures, then you'd never have to differentiate between a list and a vector. Everything would then just be a list/vector if you look deep enough, and it's always legal to do car, cdr, list-/vector-ref, and so on, on them (only set-cdr! is not supported by vectors). You would then build structures from these and you could dispatch on a type tag in the ``car'' of the list/vector, but more likely you'd have structural pattern matching.

>>10 probably means generic methods à la CLOS. So you've got these generic methods (operations), for instance: (define-generic (push adt value)). It's a function that dispatches on the type(s) of its parameters. You can define different behaviors for different specialisations of the parameter types (or values). When an instance of an ADT appears as an operand to push the most specific method will be called. A method is a function that specialises one or more parameters of a generic function i.e. (define-method (push (adt stack) value) ...push into stack...) or (define-method (push (adt queue) value) ...push onto queue...) if stack and queue are bound to ADT types. Then you can use the same function push no matter the ADT, and you don't need to know of the possible ADTs in advance.

Multiple-dispatch is also usually available.