[r6rs-discuss] comment and vote (re-definition)
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
Received on Fri Aug 24 2007 - 21:04:27 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC