[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [r6rs-discuss] redefining eqv?
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)
is not entirely the same as
(set! x 1)
(let () (set! x 2) 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