On Sat, Jul 14, 2012 at 1:51 PM, Rouben Rostamian <rostam...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
