[racket] Running Racket in the R6RS mode

On Sat, Jul 14, 2012 at 1:51 PM, Rouben Rostamian <rostamian at umbc.edu> wrote:
> Here is the entire contents of a file named tryme.rkt:
>
> ;;-----------------------------
> #!r6rs
> (import (rnrs base)
>         (rnrs sorting (6)))
> ;;-----------------------------
>
> I start up racket from the command-line (non-gui) and type:
>
> (enter! "tryme.rkt")
> (list-sort < '(4 2 7 1))  ; note: list-sort is from R6RS's sorting library
>
> This produces:
>
>      (mcons 1 (mcons 2 (mcons 4 (mcons 7 '()))))
>
> Is there a way to get a plain (1 2 4 7) representation?
>
> Aside: My objective here is to limit Racket to R6RS in the
> hope that my code will be portable to other platforms that
> implement R6RS.  If this is not the right way of going
> about it, please let me know

Hello Rouben!  You probably don't remember me, it's
been years since I took your diff eqs class :)

To add to Matthias' answer, there is an on-going effort
to create the next standard R7RS, the first part of which
(the core language) is coming to a close [disclaimer:
I'm one of the people working on this].

R6RS was very far-looking and attempted to greatly
reduce the amount of unspecified semantics in the
language.  Unfortunately, Scheme implementors are
stubborn and many refused to change, so the number
of R6RS implementations is limited.  The R7RS
standard was split into two languages - a small core
and an extended language with many libraries.  It
will still take a little time for more R7RS implementations
to become available, but almost all active implementations
have expressed intent to support at least the core.

The result is that with R7RS you will have slightly
looser semantics in the core but greater uptake.
The extended language will provide far more
libraries than R6RS.

The same problem occurred in the Common Lisp
standardization process, as noted in the following
comment from Kent Pitman:

  One problem was that Common Lisp was more descriptive than
  prescriptive. That is, if two implementation communities
  disagreed about how to solve a certain problem, CLTL was
  written in a way that sought to build a descriptive bridge
  between the two dialects in many cases rather than to force a
  choice that would bring the two into actual compatibility. This
  may even have been a correct strategy since it was most
  important in the early days just to get buy-in from the
  community on the general approach. The notion that it mattered
  for two implementations to agree was at that point a mostly
  abstract concern. There were not a lot of programs moving from
  implementation to implementation yet. As the user base later
  grew and program porting became a more widespread practice, the
  community will to invest in such matters grew. But at the time
  when CLTL was published, a sense that the language design must
  focus on true portability had not yet evolved.

  [from http://www.nhplace.com/kent/Papers/cl-untold-story.html]

We are at the same point in the Scheme standardization
process. We lack even a simple module system to be able
to share code with.  At this point in time, it's far more important
to get the different implementations on the same page first,
and worry about finer portability issues later.

While we struggle through this process, you should indeed
stick with a single implementation, and Racket is one of
the best.

-- 
Alex