Keith and Elf wrote: >>> Scheme is a beautiful language, and books like SICP can >>> help them appreciate that... but with R6RS, many of the >>> exercises will no longer work. >> >> Do you have a specific example of this? > >A quick browse through where SICP code will break (using v2 of SICP): >1.1.4, compound procedures. explanation of compound vs primitive procedures, >pg 13. >1.1.7, newtons method. sqrt redefined, pg 24. possibly different float > semantics, pg 24, as well as in exercise 1.7, pg 25. >1.2.1, linear recursion and iteration. + redefined, exercise 1.9, pg 36. >1.2.4, exponentiation. expt redefined, pg 44-45. even? redefined, pg 45. > * redefined, exercise 1.17, pg 46. >1.2.5, greatest common divisors. gcd redefined, pg 48-49. >1.3.3, procedures as general methods. sqrt redefined, pg 69. >1.3.4, procedures as returned values, sqrt redefined, pg 73, pg 75, pg 76. >2.1.3, what is meant by data?. entire section. pgs 90-93. >2.2.1, representing sequences. entire section, particularly pgs 101-103. > >im stopping here because i dont want to be typing a table of contents
There is no need to do that. With a few exeptions, all of these are examples of re-definitions of variables that are already defined by the standard (base) libraries. (I assume that you meant to say "the examples will no longer work", rather than "the exercises".) For example, 1.1.7, page 24, says: (define (sqrt n) (sqrt-iter 1.0 x)) Before getting into a big spitting contest over whether that should be forbidden, let's ask whether R6RS does, in fact, forbid it. On page 25 we read: > All explicitly exported variables are immutable in both >the exporting and importing libraries. It is thus a >syntax violation if an explicitly exported variable >appears on the left hand side of a |set!| expression, >either in the exporting or importing libraries. Note that this says that the variable can not be |set!|, but it says nothing about |define|. On page 30 we read: > The expander completes the expansion..., and then creates >the equivalent of a |letrec*| form from the defined >variables, expanded right-hand-side expressions, and >expanded body expressions. To me, this means that the variables defined in a <body> or <library body> (and so in any REPL that may be available in the implementation) are elaborated in a new scope, and therefore create new bindings that are visible within that <body>, but do not overwrite the locations bound in any imported libraries. If this interpretation is correct, then the above definition of |sqrt| is legal in a <body>, even if that <body> imports the standard definition of |sqrt|. The re-defined |sqrt| will be used if that identifer occurs in the <body>, but the standard definition will still be used in all libraries that have imported the standard definition. That seems to me to be exactly the Right Thing. If you want to write a library that uses the standard definition, but defines and exports a modified definition, I think you can do that by juggling |rename| clauses of the <import spec>. The programmer who wants to use the modified definition might need to do a bit of extra writing to ensure that the standard definition is excluded and the modified definition is used, but again that seems to me to be the Right Thing. In any case, it has nothing to do with SICP. -- Keith _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
