[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

R5RS is explicit that you can redefine EQV?. It is also explicit that doing so must not change the behavior of CASE at all.


On Wed, Dec 22, 2010 at 12:32 PM, Peter Kourzanov <peter.kourzanov@x> wrote:
On Wed, 2010-12-22 at 13:34 -0500, Eli Barzilay wrote:
> > Yes: Bigloo, STklos, and Scheme 9 all have this problem.
> (I even have the first, but didn't try it...)  I still consider it a
> plain bug, with the given the r[56]rs definition.

Frankly speaking R*RS is very silent on this: I couldn't find any
hard statement that eqv? should not be allowed to be redefined.
Somehow enforcing this is a very un-Schemey thing to do...
Here goes "everything is a function" argument...

> > I've clarified the ticket to say that standard syntax forms must be
> > implemented *as if* hygienic macros were used.
> This is an odd rephrasing.  The semantics of the forms are defined
> regardless of the implementation.  It just happens that if you want
> something that can be called sane then you need hygiene.  (This would
> change only if there are some forms that must be defined as macros,
> but such a requirment wouldn't be very practical if there are no
> standardized reflective tools to make an observable difference, like a
> specific set of core forms that `expand' should be restricted to.)

I think this particular problem is more related to "referential
transparency", in fact.

> An hour ago, Peter Kourzanov wrote:
> > And now do:
> >
> > (define eqv? equal?)
> > (newline)
> > (write (case "asd" (("asd") #t)))
> > (newline)
> >
> > You'll find Tinyscheme, Minischeme, MIT, Scheme48/SCSH included in
> > your list. Ypsilon and Stalin exhibit this behaviour for strings,
> > but not for more structured data like vectors.
> This is a *very* different issue -- R5RS systems make it a core
> feature that you can change builtin functions like that, with all
> references to them changing too.  OTOH, systems with modules have a
> completely different meaning for such definitions: usually making up a
> new binding, which means that the original macro definition uses the
> original binding which is unchanged.
> So not only do I not see an argument for some missing specification
> here, I see an argument for why the R5RS thing of overwriting global
> bindings is an insane feature.

That, I think, is a side effect of R*RS shifting focus from interpreter
semantics (where override of a global binding has application-wide
effects) to compiler semantics (where a snapshot of global bindings are
made at the time when a module is compiled).  But I might be wrong.


Scheme-reports mailing list

Scheme-reports mailing list