An hour and a half ago, John Cowan wrote:
> Eli Barzilay scripsit:
>
> > Is there really any implementation where
> >
> >   (let ((eqv? #f)) (case 1 ((1) 1)))
> >
> > throws an error?  (I don't know of any, but if there is one, it
> > should be a case for a bug report rather than something to draw
> > conclusions from.)
>
> 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.

An hour ago, John Cowan wrote:
> Andre van Tonder scripsit:
>
> > No, I think this would be wrong.  There is no requirement in R6RS
> > to implement CASE using macros at all, never mind hygienic macros.
> > The sematics of CASE is perfectly well described in R6RS as part
> > of the core, and precludes Peter's interpretation already.

+1 (since this is roughly what I said...)

> 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.)

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.

--
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

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