Re: [Scheme-reports] [r6rs-discuss] redefining eqv?

[Peter Kourzanov <peter.kourzanov@x>]

On Wed, 2010-12-22 at 18:36 -0500, Eli Barzilay wrote:

> You're confusing (or mixing) a local binding (let ((eqv? ...)) ...)
> with an implicit mutation (define eqv? ...).  

Is it? The way I read R6RS, (define) is supposed to (#1) allocate a new
location for this new eqv?, (#2) set! the result of the expression to it
and (#3) mutate the *binding* for eqv? in the environment (or splice
into parent environment when enclosed by begin). At least, that's what
it typically does for other variables. I.e.,

(define x 1)
(let () (define x 2) x)
x

is not entirely the same as

(set! x 1)
(let () (set! x 2) x)
x


And, BTW, 11.3 says that (define) is equivalent to (letrec*). So why are
these cases so different then?


To answer Andre as well,
> On Wed, 2010-12-22 at 15:55 -0500, Andre van Tonder wrote:
> It doesn't matter:
>
> From R6RS:

I agree that it shouldn't mutate the original slot of eqv?, as
prescribed by 7.1. But as I read it, R6RS says nothing about the extent
of the new eqv? *binding* (#3 above) (unlike R5RS, for the record). And
thus it can vary wildly depending on how (case) was defined.

I guess if R6RS enforced macro-implementation of (case), like Haskell's 
Prelude, the problem would be solved (via syntactic closures provided by
hygiene & referential transparency of syntax-rules).

Alternatively, if you add lazy evaluation of (case) bodies (or simulate
that with delimited continuations, whatever), you can also solve it by
using hygiene & referential transparency of functional closures with
lexical scope. But that is a different language altogether too...

> > And should we do anything about it? [...]
> 
> Depends on how "we" is defined.

I am interested in this mostly from the user perspective. I don't
know how many users are hanging around here, but I do hope this 
set is at least as large as the set of implementors...

P.S. And I have no problem in (case) using redefined eqv? as you 
     might probably have guessed. I think implementations should be
     free to make it (optionally) strict, disallowing rebinding of
     any standard keyword, maybe with define-immutable-binding.
     Otherwise there must be a way to shoot yourself in the foot.


_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports