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

[Peter Kourzanov <peter.kourzanov@x>]

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.

Pjotr



_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@x
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss