Re: [Scheme-reports] [r6rs-discuss] redefining eqv?
Peter Kourzanov 24 Dec 2010 12:23 UTC
On Thu, 2010-12-23 at 20:39 -0500, Eli Barzilay wrote:
> Earlier today, Peter Kourzanov wrote:
> > 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?
>
> ...an implicit muatation? Yes.
> ...so different? Yes.
> ...a confusion? Thats how it seems.
>
I don't agree.
11.2.1: "The first from of define binds <variable> to a new location
before assigning the value of <expression> to it."
(other forms are trivially expressed using the first)
That's exactly #1 (new location), #2 (setting the value) and #3
(binding of the new location to the given name). I can only relate
#3 to the meaning of eqv? (the name) before (define eqv? ...).
> > 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.,
>
> That's r5rs w/out any module system. Not r6rs (in a library).
>
Is there a difference? Let's see...
11.2: "Definitions may appear within a <top-level body> (section 8.1),
at the top of a <library body> (section 7.1), or at the top of a <body>
(section 11.3)."
8.1: "A <top-level body> is like a <library body> (see section 7.1),
except that definitions and expressions may occur in any order."
so => not this one,
>
> > And, BTW, 11.3 says that (define) is equivalent to (letrec*). So why
> > are these cases so different then?
>
> Because those are internal definitions.
Again, what's the difference?
Let's see...
7.1: "A <library body> is like a <body> (see section 11.3) except that a
<library body>s need not include any expressions."
so => not this one either,
Finally:
11.3: "An expanded <body> (see chapter 10) containing variable
definitions can always be converted into an equivalent letrec*
expression."
Chapter 10 goes into fine details of how to reorder according to 8.1.
>
>
> > 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).
>
> ??
Let just prescribe the "wanted" syntax-rules implementation of case in
the standard. Then there can be no confusion about its meaning and no
PhD required to understand what the standard intends but does not say.
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
